> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 送信者制約が、mTLS 証明書のサムプリントまたは DPoP プルーフキーを使用してアクセストークンを特定のクライアントに結び付け、トークンの盗難を防ぐ方法を学びます。

# 送信者制約

送信者制約は、<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> および <Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) のセキュリティメカニズムであり、アクセストークンと <Tooltip tip="Refresh Token: ユーザーに再度ログインさせることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+tokens">リフレッシュトークン</Tooltip> を要求元のアプリケーションに暗号学的に結び付けることで、トークンの盗難や不正利用を防ぎます。

従来、OAuth 2.0 の <Tooltip tip="Access Token: API へのアクセスに使用される、opaque な文字列または JWT の形式の認可クレデンシャル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+tokens">アクセストークン</Tooltip> はベアラートークンです。つまり、そのトークンを「保持」または所持している者は誰でも使用できます。ベアラートークンが盗まれたり漏えいしたりすると、攻撃者はそれを <Tooltip tip="Resource Server: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースへのリクエストを受け取り、応答します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=resource+server">リソースサーバー</Tooltip> (API) に提示し、正当なクライアントアプリケーションやユーザーになりすまして未認可のアクセスを得る可能性があります。

送信者制約により、リソースサーバーにアクセストークンを提示するクライアントアプリケーションが、そのアクセストークンの正当な所有者であることを確認できます。クライアントアプリケーションがアクセストークンの正当な所有者でない場合、リソースサーバーは API リクエストを拒否します。

<div id="how-it-works">
  ## 仕組み
</div>

送信者拘束は、次の 2 つの方法のいずれかで実装できます。

* トランスポート層における Mutual-TLS (mTLS) 証明書バインディング:

  * **メカニズム:** クライアントアプリケーションが Auth0 Authorization Server にアクセストークンをリクエストする際、相互 TLS (mTLS) 接続を確立します。この接続では、クライアントアプリケーションとサーバーの双方が互いの X.509 証明書を提示して検証します。
  * **バインディング:** Auth0 Authorization Server は、発行されたアクセストークンに、クライアントアプリケーションの証明書のサムプリントを含む確認用の (`cnf`) クレームを含めます。
  * **Proof of Possession:** クライアントアプリケーションが、バインドされたアクセストークンを使用してリソースサーバーにアクセスする際には、同じ証明書を使って再び mTLS 接続を確立する必要があります。リソースサーバーは、クライアントアプリケーションが提示した証明書が、そのアクセストークンにバインドされている証明書と一致することを検証します。一致しない場合、リソースサーバーはリクエストを拒否します。
  * **利点:** 攻撃者がアクセストークンを盗んだとしても、それを使用することはできません。正しい mTLS 接続を確立するために必要な、対応する秘密キーと証明書を持っていないためです。mTLS による送信者拘束は通常、X.509 証明書とその秘密キーを安全に保存および管理できる、サーバー側アプリケーションのような機密クライアントで使用されます。
* アプリケーション層における Demonstrating Proof-of-Possession (DPoP) :

  * **メカニズム:** DPoP はアプリケーション層で動作し、mTLS を必要としません。代わりに、クライアントアプリケーションは自身の暗号鍵ペア (秘密キー / 公開鍵) を生成します。
  * **バインディング:** アクセストークンをリクエストする際、クライアントアプリケーションは DPoP Proof JWT と呼ばれる JSON Web トークン (JWT) を作成します。この DPoP Proof JWT にはクライアントの公開鍵が含まれ、クライアントの秘密キーで署名されます。クライアントアプリケーションは、アクセストークンリクエストとともに DPoP Proof JWT を送信します。Auth0 Authorization Server は DPoP Proof JWT を検証し、その後、発行されたアクセストークンを公開鍵にバインドします。
  * **Proof of Possession:** クライアントアプリケーションが、DPoP にバインドされたアクセストークンを使用してリソースサーバーを呼び出す際、その API リクエスト用に、自身の秘密キーで署名した別の DPoP Proof JWT を生成します。クライアントアプリケーションは、アクセストークンとあわせて DPoP Proof JWT をヘッダーで送信します。リソースサーバーは、アクセストークンが DPoP Proof JWT 内の公開鍵にバインドされていること、および DPoP Proof JWT 自体が対応する秘密キーで署名されていることを、確認用 (`cnf`) クレームを使って検証します。
  * **利点:** DPoP は公開鍵基盤を必要としないため、mTLS より柔軟です。SPA やモバイルアプリケーションのようなパブリッククライアントを含む、さまざまなクライアントタイプで利用できます。

<div id="mtls-vs-dpop">
  ## mTLS と DPoP の比較
</div>

次の表は、トークンの送信者拘束における mTLS と DPoP の主な違いをまとめたものです。

| Attribute           | mTLS                    | DPoP                                     |
| ------------------- | ----------------------- | ---------------------------------------- |
| 動作レイヤー              | トランスポート層 (TLS/SSL)      | アプリケーション層 (HTTP ヘッダー)                    |
| 暗号化方式               | 公開鍵基盤 (X.509 証明書) を使用   | 非対称キー (クライアント生成のキーペア) を使用                |
| Proof of Possession | TLS ハンドシェイクと証明書のバリデーション | DPoP Proof (各リクエストの HTTP ヘッダー内の署名付き JWT) |
| クライアントタイプ           | 機密クライアント                | パブリッククライアント (SPA、モバイルアプリ)                |

詳しくは、[mTLS 送信者拘束](/docs/ja-jp/secure/sender-constraining/mtls-sender-constraining) と [Proof-of-Possession (DPoP) のデモ](/docs/ja-jp/secure/sender-constraining/demonstrating-proof-of-possession-dpop) をご覧ください。

<div id="get-started">
  ## はじめに
</div>

Auth0 の送信者制約を使い始めるには、以下をご覧ください。

| 読むもの                                                                                                            | 学べること                                        |
| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| [mTLS 送信者拘束](/docs/ja-jp/secure/sender-constraining/mtls-sender-constraining)                                   | Auth0 における mTLS 送信者制約の仕組みを、順を追って理解できます。      |
| [Proof-of-Possession (DPoP) のデモ](/docs/ja-jp/secure/sender-constraining/demonstrating-proof-of-possession-dpop) | Auth0 における DPoP の仕組みを、順を追って理解できます。           |
| [送信者制約を設定する](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining)                              | Auth0 でクライアントアプリケーションとリソースサーバーの送信者制約を設定する方法。 |

<div id="learn-more">
  ## 詳細情報
</div>

* [mTLS 送信者拘束](/docs/ja-jp/secure/sender-constraining/mtls-sender-constraining)
* [Proof-of-Possession (DPoP) のデモ](/docs/ja-jp/secure/sender-constraining/demonstrating-proof-of-possession-dpop)
* [送信者制約を設定する](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining)