3. Mutual-TLS Client Certificate-Bound Access Tokens

3. Mutual-TLS Client Certificate-Bound Access Tokens

クライアントが token endpoint への接続で mutual TLS を用いる場合, authorization server は発行した access token をクライアント証明書にバインドできる. そのバインドは, セクション 3.1 の構文で発行 access token に証明書ハッシュを直接埋め込むか, セクション 3.2 の token introspection など, 保護リソースがアクセスできる形で証明書をトークンに関連付けることで達成される. その方法で access token をクライアント証明書にバインドすると, authorization server に対するクライアント認証からバインドが切り離され, 保護リソースアクセス時の mutual TLS は純粋に proof-of-possession のメカニズムとして機能できる. authorization server と保護リソースの合意により証明書を access token に関連付ける他の方法もあり得るが, 本仕様の範囲外である.

resource server が証明書バインド access token を用いるには, 一部またはすべてのリソースアクセスに mutual TLS を用いることを事前に知っていなければならない. 特に access token 自体は mutual TLS を要求するかどうかの判断入力にはならない. TLS の観点からは "Application Data" であり TLS ハンドシェイク完了後にのみ交換され, 初期 CertificateRequest はハンドシェイク中にありアプリデータより前である. TLS 1.2 の再交渉 [RFC5246] や TLS 1.3 の post-handshake 認証 [RFC8446] など, 後続の証明書提示機会はあり得るが, 本文書はその利用を規定しない. mutual TLS を用いる resource server は, ホストするすべてのリソースに mutual TLS を要求するか, mutual-TLS 保護と通常リソースを別の hostname と port の組み合わせで提供することが一般的に想定されるが, 他のワークフローもあり得る. resource server のポリシーを authorization server (AS) と同期する方法は本文書の範囲外である.

mutual-TLS 保護のリソースアクセスフローの範囲内で, クライアントは [RFC6750] に従い保護リソース要求を行うが, それらの要求は token endpoint で mutual TLS に用いたのと同一の証明書を用いた相互認証 TLS 接続上で行わなければならない.

保護リソースは TLS 実装層から mutual TLS に用いたクライアント証明書を取得しなければならず, その証明書が access token に関連付けられた証明書と一致することを検証しなければならない. 一致しない場合, [RFC6750] に従い HTTP 401 と invalid_token でリソースアクセス試行を拒否しなければならない.

mutual-TLS クライアント証明書バインド access token のサーバおよびクライアント能力を伝えるメタデータは, それぞれセクション 3.3 および 3.4 で定義する.