> ## 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 で mTLS を使用してトークンに送信者制約を適用する方法を説明します。

# mTLS 送信者制約

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

[送信者制約](/ja/docs/secure/sender-constraining) は、<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を表示" href="/ja/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> のセキュリティメカニズムであり、アクセス用トークンと <Tooltip tip="Refresh Token: ユーザーに再度ログインさせることなく、新しい Access Token を取得するために使用されるトークン。" cta="用語集を表示" href="/ja/docs/glossary?term=refresh+tokens">リフレッシュトークン</Tooltip> を、それらを要求したクライアントアプリケーションに暗号学的に結び付けます。これにより、<Tooltip tip="Access Token: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可クレデンシャル。" cta="用語集を表示" href="/ja/docs/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 アドオンを含む Enterprise Plan を利用していること。
* Auth0 内で、クライアントアプリケーションおよび <Tooltip tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは、保護されたリソース要求を受け取り、応答します。" cta="用語集を見る" href="/ja/docs/glossary?term=resource+server">リソースサーバー</Tooltip> に対する[送信者制約の設定](/ja/docs/secure/sender-constraining/configure-sender-constraining)が完了していること。
* クライアントアプリケーションが <Tooltip tip="機密クライアント: 信頼できるバックエンドサーバーを使用して認証情報を安全に保持できるクライアント（アプリケーション）。例としては、安全なバックエンドを備えた Web アプリケーションや、マシン間（M2M）アプリケーションがあります。" cta="用語集を見る" href="/ja/docs/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="認可サーバー: ユーザーのアクセス境界の定義に寄与する一元化されたサーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/ja/docs/glossary?term=Authorization+Server">認可サーバー</Tooltip> の `/token` エンドポイントに対して TLS ハンドシェイクを開始します。
* このハンドシェイク中に、クライアントアプリケーションは相互 TLS 認証プロセスの一環として、クライアント証明書を Auth0 の認可サーバーに提示します。

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

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

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

Auth0 認可サーバーが mTLS 接続経由でトークンリクエストを受信し、クライアント証明書の検証が正常に完了すると、次の処理が行われます。

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

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

次のコードサンプルは、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 にバインドされたトークンで Bearer スキームを使用できますが、Auth0 は mTLS にバインドされたアクセストークンを強制するために 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. **サムプリントを比較 (所有証明の検証) :** リソースサーバーは、新たに計算したサムプリントを、アクセストークンの `cnf` クレーム内の `x5t#S256` サムプリントと比較します。
5. **リクエストを認可または拒否:**

   * サムプリントが一致し、有効期限、オーディエンス、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="/ja/docs/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>

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