> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Sender Constraining

> Learn how to sender constrain tokens in Auth0. 

<Warning>
  Sender constraining tokens using Demonstrating Proof-of-Possession (DPoP) is currently in Early Access. By using this feature, you agree to the applicable Free Trial terms in Okta’s [Master Subscription Agreement](https://www.okta.com/legal). To request access to this feature, contact your Auth0 representative.
</Warning>

Sender constraining is an <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=oath2" tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集の表示">OAuth 2.0</Tooltip> and <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=openid" tip="OpenID: アプリケーションがログイン情報を収集および保存することなくにユーザーのIDを検証できるようにする認証用のオープン標準。" cta="用語集の表示">OpenID</Tooltip> Connect (OIDC) security mechanism that cryptographically binds access and <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=refresh-token" tip="リフレッシュトークン: ユーザーに再度ログインを強いることなく、更新されたアクセストークンを取得するために使用されるトークン。" cta="用語集の表示">refresh tokens</Tooltip> to the application that requested them, preventing token theft and misuse.

Traditionally, OAuth 2.0 <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=access-token" tip="アクセストークン: APIへのアクセスに使用される、不透明な文字列またはJWT形式の認可資格情報。" cta="用語集の表示">access tokens</Tooltip> are bearer tokens, which means whoever “bears” or possesses the token can use it. If a bearer token is stolen or leaked, an attacker can present it to a <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-6" href="/docs/ja-jp/glossary?term=resource-server" tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースの要求を受け入れ、応答します。" cta="用語集の表示">resource server</Tooltip> (API) and gain unauthorized access by impersonating the legitimate client application or user.

Sender constraining ensures that the client application presenting the access token to a resource server is the valid owner of the access token. If the client application is not the valid owner of the access token, then the resource server rejects the API request.

## How it works

You can implement sender constraining in one of two ways:

* Mutual-TLS (mTLS) certificate binding in the transport layer:

  * **Mechanism:** When the client application requests an access token from the Auth0 Authorization Server, it establishes a mutual TLS (mTLS) connection, where both the client application and the server present and verify each other's X.509 certificates.
  * **Binding:** The Auth0 Authorization Server includes a confirmation (`cnf`) claim that includes the thumbprint of the client application's certificate directly within the issued access token.
  * **Proof of Possession:** When the client application uses the mTLS-bound access token to access a resource server, it must again establish an mTLS connection using the same certificate. The resource server verifies that the certificate presented by the client application matches the one bound to the access token. If they don't match, the resource server rejects the request.
  * **Benefit:** Even if an attacker steals the access token, they cannot use it because they won't possess the corresponding private key and certificate required to establish the correct mTLS connection. mTLS sender constraining is typically used by confidential clients such as server-side applications that can securely store and manage X.509 certificates and their private keys.
* Demonstrating Proof-of-Possession (DPoP) in the application layer:

  * **Mechanism:** DPoP operates at the application layer and doesn't require mTLS. Instead, the client application generates a cryptographic key pair (private/public key) for itself.
  * **Binding:** When requesting an access token, the client application creates a JSON Web Token (JWT) called a DPoP Proof JWT. This proof JWT contains the client's public key and is signed by the client's private key. The client application sends the DPoP Proof JWT along with the access token request. The Auth0 Authorization Server validates the DPoP Proof JWT and then binds the issued access token to the public key.
  * **Proof of Possession:** When the client application uses the DPoP-bound access token to call a resource server, it generates another DPoP Proof JWT signed with its private key for that API request. The client application sends the DPoP Proof JWT in a header alongside the access token. The resource server verifies that the access token is bound to the public key in the DPoP Proof JWT, and that the DPoP Proof JWT itself has been signed by the corresponding private key using a confirmation (`cnf`) claim.
  * **Benefit:** DPoP is more flexible than mTLS because it doesn't require a public key infrastructure. Various client types can use it, including public clients like SPAs and mobile applications.

## mTLS vs. DPoP

The following table summarizes the high-level differences between mTLS and DPoP for sender constraining tokens:

| Attribute           | mTLS                                                 | DPoP                                                    |
| ------------------- | ---------------------------------------------------- | ------------------------------------------------------- |
| Layer of operation  | Transport layer (TLS/SSL)                            | Application layer (HTTP headers)                        |
| Cryptography        | Using Public Key Infrastructure (X.509 Certificates) | Using asymmetric keys (Client-generated key pairs)      |
| Proof of Possession | TLS handshake and certificate validation             | DPoP Proof (signed JWT in HTTP header for each request) |
| Client type         | Confidential clients                                 | Public clients (SPAs, mobile apps)                      |

To learn more, read [mTLS Sender Constraining](/docs/ja-jp/secure/sender-constraining/mtls-sender-constraining) and [Demonstrating Proof-of-Possession (DPoP)](/docs/ja-jp/secure/sender-constraining/demonstrating-proof-of-possession-dpop).

## Get started

To get started with Sender Constraining at Auth0, read the following:

| Read                                                                                                                      | To learn                                                                                    |
| ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| [mTLS Sender Constraining](/docs/ja-jp/secure/sender-constraining/mtls-sender-constraining)                               | How mTLS sender constraining works in Auth0, step by step.                                  |
| [Demonstrating Proof-of-Possession (DPoP)](/docs/ja-jp/secure/sender-constraining/demonstrating-proof-of-possession-dpop) | How DPoP works in Auth0, step by step.                                                      |
| [Configure Sender Constraining](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining)                     | How to configure sender constraining for a client application and resource server in Auth0. |

## もっと詳しく

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