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

​
前提条件

mTLS の送信者制約を実装するには、次の要件を満たしている必要があります。
  • Auth0 テナントで、Highly Regulated Identity アドオンを含む Enterprise Plan を利用していること。
  • Auth0 内で、クライアントアプリケーションおよび に対する送信者制約の設定が完了していること。
  • クライアントアプリケーションが であること。mTLS の送信者制約をサポートするのは機密クライアントのみです。

​
仕組み

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

​
フェーズ 1: mTLS にバインドされたアクセストークンをリクエストする

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

  • アクセストークンをリクエストする前に、クライアントアプリケーションは Auth0 の の /token エンドポイントに対して TLS ハンドシェイクを開始します。
  • このハンドシェイク中に、クライアントアプリケーションは相互 TLS 認証プロセスの一環として、クライアント証明書を Auth0 の認可サーバーに提示します。

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

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

​
ステップ 3: Auth0 認可サーバーがリクエストを処理し、トークンをバインドする

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 証明書にバインドされたアクセストークンのペイロード例です。 
{
  "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 クライアント証明書にバインドされていることを示します。

​
フェーズ 2: mTLS にバインドされたアクセストークンを使用して API を呼び出す

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

  • クライアントアプリケーションが mTLS の送信者制約を適用する API を呼び出す必要がある場合は、リソースサーバーに対して新たに mTLS 接続を確立する必要があります。
  • この mTLS ハンドシェイク中に、クライアントアプリケーションは、アクセストークンの取得時に使用したものと同じクライアント証明書を再度提示します。
  • 次に、クライアントアプリケーションは、DPoP 認証スキームを使用して、mTLS にバインドされたアクセストークンを API リクエストの Authorization ヘッダーに含めます。
Authorization: DPoP {your_mtls_bound_access_token}
RFC 8705 では、mTLS にバインドされたトークンで Bearer スキームを使用できますが、Auth0 は mTLS にバインドされたアクセストークンを強制するために DPoP を使用することを推奨しています。これにより、リソースサーバーに対して、暗号学的にバインドされたトークンを想定すべきであることを明示的に伝えられます。

​
ステップ 5: リソースサーバーがトークンと証明書を検証する

リソースサーバーが 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 を参照してください。

​
重要な考慮事項

mTLS の送信者制約を実装する際は、次の点に注意してください。
  • 機密クライアントのみ: mTLS の送信者制約は、クライアント証明書を安全に管理し、mTLS 接続を確立できるバックエンドサービスなどの機密クライアント向けに設計されており、それらのみがサポート対象です。である SPA やモバイルアプリでは、DPoP を使用する必要があります。
  • 証明書管理: mTLS 実装の安全性は、クライアント証明書をどのようにプロビジョニング、管理、ローテーションするかといった、証明書管理の運用に大きく依存します。
  • インフラストラクチャ要件: mTLS の実装には、mTLS 接続を終端し、クライアント証明書の情報をアプリケーションまたはリソースサーバーに渡せるプロキシ、ロードバランサー、API など、特定のインフラストラクチャが必要です。
  • リソースサーバーによる強制: Auth0 で API に対して mTLS の送信者制約を有効にした場合、リソースサーバーは Step 5 で説明されているとおり、サムプリントを検証する必要があります。
  • 移行戦略: クライアントを段階的に mTLS に移行している場合は、API を 2 つのドメインで公開することを検討してください。1 つは既存クライアント向けの非 mTLS ドメイン、もう 1 つは mTLS 対応クライアント向けの mTLS 対応ドメインです。あるいは、単一のドメインで mTLS リクエストと非 mTLS リクエストを区別するロジックを実装することもできます。
  • エラー処理: 証明書がない、無効である、または一致しない場合を適切に処理できるよう、クライアントとリソースサーバーの両方で堅牢なエラー処理を実装してください。

​
関連情報