> ## 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 証明書に結び付け、その証明書の保持者だけがトークンを使用してリソースサーバーを呼び出せるようにします。

# mTLS 送信者制約

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Highly Regulated Identity 機能を使用するには、Highly Regulated Identity add-on を含む Enterprise Plan が必要です。詳しくは [Auth0 Pricing](https://auth0.com/pricing/) を参照してください。
</Callout>

[送信者拘束](/docs/ja-jp/secure/sender-constraining) は、<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> のセキュリティメカニズムであり、<Tooltip tip="Access Token: API へのアクセスに使用される、opaque 文字列または JWT の形式の認可資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">アクセストークン</Tooltip> と <Tooltip tip="Refresh Token: ユーザーに再度ログインを求めることなく、新しい Access Token を取得するために使用されるトークン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+tokens">リフレッシュトークン</Tooltip> を、それらを要求したクライアントアプリケーションに暗号学的に結び付けます。これにより、<Tooltip tip="Access Token: API へのアクセスに使用される、opaque 文字列または JWT の形式の認可資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">アクセストークン</Tooltip> を取得した正当なクライアントのみが、そのトークンを使用して保護されたリソースにアクセスできるようになり、トークンの窃取やリプレイ攻撃に対する強力な防御になります。

Mutual-TLS (mTLS) Client Certificate-Bound Access Tokens (mTLS 送信者拘束) は、クライアントの TLS 証明書を利用してこの結び付けを実現します。mTLS では、クライアントのアクセストークンがその一意のクライアント証明書に結び付けられるため、そのトークンを他者が使用することはできません。

<div id="prerequisites">
  ## 前提条件
</div>

mTLS 送信者拘束を実装するには、以下を満たしている必要があります。

* Auth0 テナントで、Highly Regulated Identity add-on を含む Enterprise Plan を利用していること。
* クライアントアプリケーションおよび Auth0 内の <Tooltip tip="Resource Server: 保護されたリソースをホストするサーバー。リソースサーバーは、保護されたリソースへのリクエストを受け取り、それに応答します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=resource+server">リソースサーバー</Tooltip> に対して、[送信者拘束を設定](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining) していること。
* クライアントアプリケーションが <Tooltip tip="Confidential Client: 信頼できるバックエンドサーバーを使用して資格情報を安全に保持できるクライアント（アプリケーション）。例としては、安全なバックエンドを持つ Web アプリケーションや、machine-to-machine（M2M）アプリケーションがあります。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=confidential+client">機密クライアント</Tooltip> であること。mTLS 送信者拘束をサポートしているのは、機密クライアントのみです。

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

このセクションでは、mTLS にバインドされたアクセストークンを取得して使用する流れを説明します。

<Frame>
  <img src="https://mintcdn.com/translations/mMSz-RNYLuOm2GmQ/docs/images/cdy7uua7fh8z/Nrf2Jm8Gq1yuMlS35jqDR/3972d735b883ea1ce5ae0999b678db2f/Screenshot_2025-07-30_at_4.07.34_PM.png?fit=max&auto=format&n=mMSz-RNYLuOm2GmQ&q=85&s=55ae89a9b547b93daf8645b891e9a36c" alt="" width="1222" height="852" data-path="docs/images/cdy7uua7fh8z/Nrf2Jm8Gq1yuMlS35jqDR/3972d735b883ea1ce5ae0999b678db2f/Screenshot_2025-07-30_at_4.07.34_PM.png" />
</Frame>

<div id="phase-1-request-an-mtls-bound-access-token">
  ## フェーズ 1: mTLS にバインドされたアクセストークンをリクエストする
</div>

<div id="step-1-client-application-establishes-mtls-connection">
  ### ステップ 1: クライアントアプリケーションが mTLS 接続を確立する
</div>

* アクセストークンをリクエストする前に、クライアントアプリケーションは Auth0 <Tooltip tip="Authorization Server: ユーザーのアクセス範囲の境界を定義する役割を担う中央サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Server">Authorization Server</Tooltip> の `/token` エンドポイントとの間で TLS ハンドシェイクを開始します。
* このハンドシェイク中に、クライアントアプリケーションは相互 TLS 認証プロセスの一環として、Auth0 Authorization Server にクライアント証明書を提示します。

<div id="step-2-client-application-requests-access-token">
  ### ステップ 2: クライアントアプリケーションがアクセストークンをリクエストする
</div>

* クライアントアプリケーションは、`grant_type=client_credentials` や `authorization_code` などを使用して、標準的な OAuth 2.0 のトークンリクエストを Auth0 Authorization Server の `/token` エンドポイントに送信します。
* このトークンリクエストには、mTLS 用の特別な DPoP ヘッダーや、追加の証明としての <Tooltip tip="JSON Web Token (JWT): 2 者間でクレームを安全に表現するために使用される標準の ID トークン形式（多くの場合、アクセストークン形式としても使用されます）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=JWTs">JWTs</Tooltip> は含まれません。所持証明は mTLS 接続自体から直接得られます。

<div id="step-3-auth0-authorization-server-processes-request-and-binds-token">
  ### Step 3: Auth0 Authorization Server がリクエストを処理し、トークンをバインドする
</div>

Auth0 Authorization Server が mTLS 接続経由でトークンリクエストを受信し、クライアント証明書の検証に成功すると、次の処理が行われます。

1. **証明書を抽出:** Auth0 Authorization Server は、mTLS ハンドシェイクで使用されたクライアント証明書を抽出します。
2. **サムプリントを計算:** Auth0 Authorization Server は、クライアント証明書の一意のハッシュ値 (サムプリント) を計算します。
3. **トークンをバインド:** Auth0 Authorization Server は、アクセストークンのペイロードに確認用クレーム (`cnf`) を含めることで、このクライアント証明書のサムプリントを発行済みのアクセストークンにバインドします。

   * `cnf` クレームには `x5t#S256` パラメーターが含まれており、これはクライアント証明書の SHA-256 サムプリントを Base64url エンコードしたものです。
4. **`token_type` を設定:** Auth0 Authorization Server は `token_type` を DPoP に設定します。これは従来の Bearer トークンとは異なり、そのトークンが特定の鍵にバインドされていることを示します。
5. **トークンを発行:** Auth0 Authorization Server は、mTLS の sender-constrained アクセストークンをクライアントアプリケーションに発行します。

以下のコードサンプルは、mTLS 証明書にバインドされたアクセストークンのペイロードの例です。

```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 証明書にバインドされたアクセストークンの例では、`x5t#S256` は、そのアクセストークンが SHA-256 サムプリント `bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2` を持つ mTLS クライアント証明書にバインドされていることを示しています。

<div id="phase-2-call-an-api-with-an-mtls-bound-access-token">
  ## フェーズ2: mTLS にバインドされたアクセストークンを使用して API を呼び出す
</div>

<div id="step-4-client-application-calls-api">
  ### ステップ 4: クライアントアプリケーションが API を呼び出す
</div>

* クライアントアプリケーションが mTLS の送信者拘束を適用する API を呼び出す必要がある場合は、リソースサーバーとの間で新たに mTLS 接続を確立する必要があります。
* この mTLS ハンドシェイクでは、クライアントアプリケーションはアクセストークンの取得時に使用したものと同じクライアント証明書を再度提示します。
* その後、クライアントアプリケーションは、DPoP 認証スキームを使用して、mTLS にバインドされたアクセストークンを API リクエストの Authorization ヘッダーに含めます。

```http lines theme={null}
Authorization: DPoP {your_mtls_bound_access_token}
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  RFC 8705 では mTLS-bound トークンで Bearer スキームを使用できますが、Auth0 は mTLS-bound アクセストークンの適用には DPoP の使用を推奨しています。これにより、リソースサーバーに対して、暗号学的に関連付けられたトークンを想定するよう明確に示せます。
</Callout>

<div id="step-5-resource-server-verifies-token-and-certificate">
  ### ステップ 5: リソースサーバーがトークンと証明書を検証する
</div>

リソースサーバーが mTLS 接続経由で API リクエストを受信すると、次の処理を行います。

1. **クライアント証明書を取得する:** リソースサーバーは、確立済みの mTLS 接続からクライアント証明書を取得します。
2. **トークンと `cnf` クレームを抽出する:** リソースサーバーは `Authorization` ヘッダーからアクセストークンを取り出し、そのペイロードをデコードして `cnf` (confirmation) クレーム、特に `x5t#S256` の値 (バインドされた証明書のサムプリント) を確認します。
3. **現在の証明書のサムプリントを計算する:** リソースサーバーは、現在の mTLS 接続で受信したクライアント証明書の SHA-256 サムプリントを計算します。
4. **サムプリントを比較する (Proof-of-Possession の検証) :** リソースサーバーは、新たに計算したサムプリントを、アクセストークンの `cnf` クレームに含まれる `x5t#S256` のサムプリントと比較します。
5. **リクエストを認可または拒否する:**

   * サムプリントが一致し、有効期限、audience、issuer など、その他のトークン検証にも成功した場合、そのリクエストは認可されます。
   * クライアント証明書が送信されなかった場合、またはそのサムプリントが `cnf` クレーム内のものと一致しない場合、リソースサーバーは `HTTP 401 Unauthorized` ステータスコードと `invalid_token` エラーコードを返して、リクエストを拒否します。

サムプリントの計算方法と `cnf` クレームの形式については、RFC 8705: Mutual-TLS Client Certificate-Bound Access Tokens を参照してください。

<div id="important-considerations">
  ## 重要な考慮事項
</div>

mTLSの送信者拘束を実装する際は、次の点を考慮してください。

* **機密クライアントのみ:** mTLSの送信者拘束は、クライアント証明書を安全に管理し、mTLS接続を確立できるバックエンドサービスなどの機密クライアントのみを対象に設計されており、サポートもそれらに限定されます。<Tooltip tip="パブリッククライアント: 資格情報を安全に保持できないクライアント（アプリケーション）。例としては、ネイティブのデスクトップまたはモバイルのアプリケーションや、JavaScriptベースのクライアント側Webアプリケーション（シングルページアプリケーション（SPA）など）が含まれます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Public+clients">パブリッククライアント</Tooltip> (SPAやモバイルアプリなど) では、DPoPを使用する必要があります。
* **証明書管理:** mTLS実装の安全性は、クライアント証明書をどのようにプロビジョニング、管理、ローテーションするかといった、証明書管理の運用に大きく依存します。
* **インフラストラクチャ要件:** mTLSを実装するには、プロキシ、ロードバランサー、mTLS接続を終端し、クライアント証明書情報をアプリケーションまたはリソースサーバーに渡せるAPIなど、特定のインフラストラクチャが必要です。
* **リソースサーバーでの検証適用:** Auth0でAPIに対してmTLSの送信者拘束を有効にする場合、リソースサーバーは[Step 5](#step-5-resource-server-verifies-token-and-certificate)で説明されているとおり、サムプリントの検証を実行する必要があります。
* **移行戦略:** クライアントを段階的にmTLSへ移行している場合は、APIを2つのドメインで公開することを検討してください。1つは既存クライアント向けの非mTLSドメイン、もう1つはmTLS対応クライアント向けのmTLS対応ドメインです。あるいは、単一のドメイン上でmTLSリクエストと非mTLSリクエストを区別するロジックを実装することもできます。
* **エラー処理:** 証明書が存在しない、無効である、または一致しない場合にも適切に対処できるよう、クライアントとリソースサーバーで堅牢なエラー処理を実装してください。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [送信者制約を設定する](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining)