メインコンテンツへスキップ
Highly Regulated Identity 機能を使用するには、Highly Regulated Identity アドオン付きの Enterprise Plan が必要です。詳細は Auth0 Pricing を参照してください。
Sender constraining は、アクセストークンや を、それらを要求したクライアントアプリケーションに暗号学的に結び付ける、 のセキュリティメカニズムです。これにより、 を取得した正当なクライアントだけが、そのトークンを使用して保護されたリソースにアクセスできるようになり、トークンの窃取やリプレイ攻撃に対する強力な防御を提供します。 Mutual-TLS (mTLS) Client Certificate-Bound Access Tokens（クライアント証明書バインド型アクセストークン）、すなわち mTLS sender constraining は、クライアントの TLS 証明書を利用することでこのバインディングを実現します。mTLS では、クライアントのアクセストークンはそのクライアント固有の証明書にバインドされるため、そのトークンは他のいかなる当事者によっても使用できません。

​
前提条件

mTLS センダー制約を実装するには、次の条件を満たす必要があります。
  • Auth0 テナントで、Highly Regulated Identity アドオン付きの Enterprise プランを利用していること。
  • Auth0 内のクライアント アプリケーションおよびに対して、センダー制約を構成していること。
  • クライアント アプリケーションがであること。なお、mTLS センダー制約をサポートするのは機密クライアントのみです。

​
動作の仕組み

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

​
Phase 1: Request an mTLS-bound access token

​
ステップ 1: クライアントアプリケーションが mTLS 接続を確立する

  • アクセストークンを要求する前に、クライアントアプリケーションは Auth0 の /token エンドポイントに対して TLS ハンドシェイクを行います。
  • このハンドシェイク中に、クライアントアプリケーションは相互 TLS 認証プロセスの一環として、自身のクライアント証明書を Auth0 の Authorization Server に提示します。

​
ステップ 2: クライアントアプリケーションがアクセストークンをリクエストする

  • クライアントアプリケーションは、grant_type=client_credentials や authorization_code などを使用して、Auth0 認可サーバーの /token エンドポイントに標準的な OAuth 2.0 トークンリクエストを送信します。
  • トークンリクエストには、DPoP ヘッダーや mTLS のための追加の所有証明用 は含まれません。所有証明は mTLS 接続から直接導出されます。

​
Step 3: Auth0 Authorization Server processes request and binds token

When the Auth0 Authorization Server receives the token request over an mTLS connection and the client certificate is successfully validated:
  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 センダー制約付きアクセストークンをクライアントアプリケーションに発行します。
The following code sample is an example payload of an mTLS certificate-bound access token: 
{
  "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 クライアント証明書にバインドされていることを示しています。

​
Phase 2: Call an API with an mTLS-bound access token

​
Step 4: クライアントアプリケーションが API を呼び出す

  • クライアントアプリケーションが mTLS sender constraining を要求する API を呼び出す必要がある場合、リソースサーバーとの間で新しい mTLS 接続を確立する必要があります。
  • この mTLS ハンドシェイク中に、クライアントアプリケーションはアクセストークンの取得に使用したものと同じクライアント証明書を再度提示します。
  • その後、クライアントアプリケーションは、DPoP 認証方式を使用して、API リクエストの Authorization ヘッダーに mTLS にバインドされたアクセストークンを含めます。
Authorization: DPoP {your_mtls_bound_access_token}
RFC 8705 では mTLS にバインドされたトークンに対して Bearer スキームを使用することもできますが、Auth0 では mTLS にバインドされたアクセストークンを必須とする手段として DPoP を使用することを推奨します。これにより、リソースサーバーに対して暗号的にバインドされたトークンを受け取ることを明示的に伝えます。

​
Step 5: Resource server verifies token and certificate

When the resource server receives the API request over an mTLS connection:
  1. Requests client certificate: The resource server retrieves the client certificate from the established mTLS connection.
  2. Extracts token and cnf claim: The resource server extracts the access token from the Authorization header and decodes its payload to find the cnf (confirmation) claim, specifically the x5t#S256 value (the bound certificate’s thumbprint).
  3. Calculates current certificate thumbprint: The resource server calculates the SHA-256 thumbprint of the client certificate received in the current mTLS connection.
  4. Compares thumbprints (Proof-of-Possession verification): The resource server compares the newly calculated thumbprint with the x5t#S256 thumbprint from the access token’s cnf claim.
  5. Authorizes or rejects request:
    • If the thumbprints match and other token validations, such as the expiration, audience, and issuer, pass, the request is authorized.
    • If the client certificate was not sent, or its thumbprint does not match the one in the cnf claim, the resource server rejects the request with an HTTP 401 Unauthorized status code and an invalid_token error code.
To understand how the thumbprint is calculated and the format of the cnf claim, refer to RFC 8705: Mutual-TLS Client Certificate-Bound Access Tokens.

​
重要な考慮事項

mTLS sender constraining を実装する際は、次の点を考慮してください。
  • 機密クライアントのみ: mTLS sender constraining は、クライアント証明書を安全に管理し、mTLS 接続を確立できるバックエンドサービスなどの機密クライアント専用に設計され、サポートされています。は DPoP を使用する必要があります。
  • 証明書管理: mTLS 実装のセキュリティは、クライアント証明書のプロビジョニング、管理、ローテーション方法といった証明書管理の運用に大きく依存します。
  • インフラストラクチャ要件: mTLS を実装するには、プロキシ、ロードバランサー、mTLS 接続を終端しクライアント証明書情報をアプリケーションまたはリソースサーバーへ渡すことができる API など、特定のインフラストラクチャが必要です。
  • リソースサーバーでの適用: Auth0 で API に対して mTLS sender constraining を有効にした場合、リソースサーバーは ステップ 5 で説明しているとおり、フィンガープリント検証を実行する必要があります。
  • 移行戦略: クライアントを段階的に mTLS 利用へ移行している場合は、API を 2 つのドメインで公開することを検討してください。既存クライアント向けの非 mTLS ドメインと、mTLS 対応クライアント向けの mTLS 有効ドメインです。あるいは、単一のドメイン上で mTLS リクエストと非 mTLS リクエストを区別するロジックを実装することもできます。
  • エラー処理: クライアントおよびリソースサーバー側で堅牢なエラー処理を実装し、証明書が存在しない場合、不正な場合、または一致しない場合でも円滑に対処できるようにしてください。

​
詳細