mTLS 送信者制約

アクセストークンをクライアントの mTLS 証明書に結び付け、その証明書の保持者だけがトークンを使用してリソースサーバーを呼び出せるようにします。

Highly Regulated Identity 機能を使用するには、Highly Regulated Identity add-on を含む Enterprise Plan が必要です。詳しくは Auth0 Pricing を参照してください。

送信者拘束 は、OAuth 2.0 のセキュリティメカニズムであり、アクセストークン と リフレッシュトークン を、それらを要求したクライアントアプリケーションに暗号学的に結び付けます。これにより、アクセストークン を取得した正当なクライアントのみが、そのトークンを使用して保護されたリソースにアクセスできるようになり、トークンの窃取やリプレイ攻撃に対する強力な防御になります。

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

​

前提条件

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

• Auth0 テナントで、Highly Regulated Identity add-on を含む Enterprise Plan を利用していること。
• クライアントアプリケーションおよび Auth0 内の リソースサーバー に対して、送信者拘束を設定 していること。
• クライアントアプリケーションが 機密クライアント であること。mTLS 送信者拘束をサポートしているのは、機密クライアントのみです。

​

仕組み

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

​

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

​

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

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

​

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

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

​

Step 3: Auth0 Authorization Server がリクエストを処理し、トークンをバインドする

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 証明書にバインドされたアクセストークンのペイロードの例です。

{
  "iss": "https://server.example.com",
  "sub": "[e-mail]",
  "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-bound トークンで Bearer スキームを使用できますが、Auth0 は mTLS-bound アクセストークンの適用には DPoP の使用を推奨しています。これにより、リソースサーバーに対して、暗号学的に関連付けられたトークンを想定するよう明確に示せます。

​

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

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

​

重要な考慮事項

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

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

​

詳しくはこちら

• 送信者制約を設定する