> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 送信者制約を構成する > Auth0テナントの送信者制約を構成する方法の概要です。ハイリーレギュレーテッドアイデンティティ機能を使用するには、エンタープライズプランとハイリーレギュレーテッドアイデンティティアドオンが必要です。詳細については、「[Auth0の価格設定](https://auth0.com/pricing/)」を参照してください。送信者制約（別名トークンバインディング）は、アクセストークンを秘密鍵などの暗号鍵にバインドできるようにします。これにより、アクセストークンを要求したアプリケーションのみが、これを使用して関連するリソースにアクセスできるようになり、トークンの盗難やリプレイ攻撃が軽減されます。 Highly Regulated Identityは、「mTLSトークンバインディング」としても知られる[相互TLSクライアント証明書バインドアクセストークン](https://www.rfc-editor.org/rfc/rfc8705)を通じてトークン制約機能を提供します。送信者制約の構成方法の詳細は、以下を参照してください。 * [送信者制約用にクライアントを構成する](/docs/ja-jp/configure-client-for-sender-constraining) * [Sender Constraining用にリソースサーバーを構成する](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining/configure-resource-server-for-sender-constraining) ## アクセストークンが証明書にバインドされる仕組み [機密クライアント](/docs/ja-jp/get-started/applications/confidential-and-public-applications#confidential-applications)のみがmTLSのトークンバインディングに対応しています。 [アプリケーションをmTLS用に設定](/docs/ja-jp/get-started/applications/configure-mtls/configure-mtls-for-a-client)した後、アプリケーションは相互TLSを使用してアクセストークンを要求できるようになります。認可サーバーは、アクセストークンのペイロードに確認クレーム（`cnf`）を含めることによって、クライアント証明書を発行されたアクセストークンにバインドします。この`cnf`には、クライアント証明書のサムプリントを表すハッシュが含まれています。以下のコード例は、証明書にバインドされたアクセストークンのペイロードを示しています。 ```json lines theme={null} { "iss": "https://server.example.com", "sub": "ty.webb@example.com", "exp": 1493726400, "nbf": 1493722800, "cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" } } ``` ## トークンの検証 mTLSトークンバインディングが有効になると、アクセストークンは、これらを要求したアプリケーション（つまり「送信者」アプリケーション）の制約を受けることになります。リソースサーバーは、要求で送信されたクライアント証明書がアクセストークントークンに含まれるものと同じサムプリントを持っていることを検証する責任があります。これは「Proof-of-possession（所有の証明）」の検証とも呼ばれています。アプリケーションが証明書にバインドされたアクセストークントークンを使用する権限があることを検証するために、リソースサーバーは要求で使用されたクライアント証明書のサムプリントを生成し、それを`cnf`クレームのサムプリントと比較する必要があります。`cnf`クレームの形式と証明書のサムプリントの生成方法に関する詳細は、RFC 8705の「[JWT Certificate Thumbprint Confirmation Method（JWT証明書サムプリント確認方法）](https://www.rfc-editor.org/rfc/rfc8705#name-jwt-certificate-thumbprint-)」に関するセクションを参照してください。アプリケーションが要求にクライアント証明書を送信しなかった場合、またはクライアント証明書のサムプリントが一致しなかった場合、リソースサーバーは、`HTTP 401`ステータスコードおよび`invalid_token`エラーコードを使用して、その要求を拒否します。以下の表は、[アプリケーション](/docs/ja-jp/get-started/applications/configure-mtls/configure-mtls-for-a-client)（OAuthクライアント）と[API](/docs/ja-jp/get-started/applications/configure-mtls/set-up-resource-server-for-token-binding)（OAuthリソースサーバー）のmTLS設定に基づいて、発行されたトークンが送信者制約を受けているかどうかを説明したものです。この表は、以下のシナリオに対応しています。 * 要求されたオーディエンスのタイプ：`userinfo`のみ、または`userinfo`を含むカスタムオーディエンス * 送信者制約がクライアントによって`required`とされているかどうか * リソースサーバーに対して送信者制約が設定されているかどうか： * `none`：リソースサーバーに対して送信者制約が設定されていません。 * `allowed`：mTLSを送信者制約メソッドとして設定することで、リソースサーバーに対して送信者制約が構成されています。 * `required`：リソースサーバーに対して送信者制約が必須とされています。つまりアクセストークンは、アプリケーションに対する送信者制約を受けている必要があります。送信者制約メソッドが必要です。 * クライアントアプリケーションが、トークン要求にProof-of-Possession（所有の証明）アサーションを送信したかどうか。 null