> ## 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.

> Auth0 でトークンに送信者制約を適用する方法を学びます。

# 送信者制約

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

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

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

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

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

* トランスポート層での相互 TLS (mTLS) 証明書バインディング:

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

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

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

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

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

詳細については、[mTLS Sender Constraining](/ja/docs/secure/sender-constraining/mtls-sender-constraining) と [Demonstrating Proof-of-Possession (DPoP)](/ja/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop) を参照してください。

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

Auth0 で 送信者制約 を使い始めるには、次のドキュメントを参照してください。

| 参照先                                                                                                                    | 学べること                                          |
| ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
| [mTLS 送信者制約](/ja/docs/secure/sender-constraining/mtls-sender-constraining)                                             | Auth0 における mTLS 送信者制約 の仕組みを、順を追って説明します。        |
| [Demonstrating Proof-of-Possession (DPoP)](/ja/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop) | Auth0 における DPoP の仕組みを、順を追って説明します。              |
| [Configure 送信者制約](/ja/docs/secure/sender-constraining/configure-sender-constraining)                                   | Auth0 でクライアントアプリケーションとリソースサーバーの 送信者制約 を設定する方法。 |

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

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