「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
※ このページは、ドラフト 07 を参考にして作成。
シーケンス †
Client - Authorization Server †
- Token EndpointでMutual TLSクライアント認証する。
- X.509証明書のHashによりClientとAccess Tokenを結び付ける。
Client - Resource Server †
- Resource EndPoint?でMutual TLSクライアント認証する。
- Resource Serverは、X.509証明書のHashと、Access Tokenの結び付けを検証する。
方法 †
任意だが、Access TokenをJWTにして、その中に証明書のハッシュを埋め込む。
メリット・デメリット †
メリット †
- Client自体は殆ど何も変えなくて良い。
- 対応しなければならないのはServer側。
デメリット †
- Client側からは、Serverがそのトークンを「持参人切符」として扱ったのか「記名式切符」として扱ったのかわからない。
- Client自身のリスク管理には、その情報が必要なので、同じリソースURIは、「持参人切符」は取り扱ってはならない。
- 異なるAuthorization Schemeではなく、Bearerスキーマをそのまま使うのは、英国のOpen Bankingでの採用のしやすさに配慮した結果。
対象のEndPoint? †
Authorization Serverの下記のエンドポイントにクライアント認証の追加メカニズムを提供。
詳細 †
クライアント証明書によるクライアント認証 †
- client_idパラメタが必須
クライアント証明書の内容とは独立してClientを識別するため。
- クライアント証明書をClient Credentialsとして使用して、
client_idをバインドする2つの異なった方法がある。
クライアント証明書のPKIによる認証方式 †
- 証明書チェーンとサブジェクト識別名（DN）を使用する方式
- 証明書チェーンの検証：TLSハンドシェイクにより公開鍵に対応する秘密鍵の所有を検証する。
- サブジェクト識別名（DN）：証明書内の件名情報と一致するか確認
- [IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
- PKI認証方式メタデータ値
- tls_client_auth
- クライアント認証にクライアント証明書のPKIを使用する。
- クライアント登録メタデータ
- tls_client_auth_subject_dn
- クライアント証明書の予想されるサブジェクト識別名の文字列表現。
※ クライアント証明書の入れ替えは自由に行うことが出来る。
自己署名クライアント証明書によるクライアント認証方式 †
- 証明書自体（または信頼できるソース）をAuthorization Serverに登録する方式
- [IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
- 自己署名証明書認証方式メタデータ値
- self_signed_tls_client_auth
- クライアント認証にクライアント証明書を使用する。
送信者制限付きAccess Token †
- ClientがTokenエンドポイントへの接続でクライアント証明書を使用すると、
Authorization Serverは発行されたAccess Tokenをクライアント証明書にバインドできる。
- Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
（証明書が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。）
- なお、[IANA.JWT.Claims] for JWT "cnf"メンバー値は[RFC7800]によって確立されている。
バインド方式 †
Access Tokenをクライアント証明書にバインドする方式。
- Access Tokenに証明書ハッシュを埋め込む
- JWTのx5t#S256 (SHA-256による証明書フィンガープリント)を使用する。
- 以下は、x5t#S256 (SHA-256による証明書フィンガープリント)を含むJWTペイロードの例。
{
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf":{
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}
}
- Introspectionエンドポイントで関連付ける
（この仕様の範囲外）だが、Introspectionエンドポイントから以下のような、
x5t#S256 (SHA-256による証明書フィンガープリント)を含むメタデータを返す。
HTTP/1.1 200 OK
Content-Type: application/json
{
"active": true,
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf":{
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}
}
メタデータ †
- Authorization Server
- mutual_tls_sender_constrained_access_tokens
- クライアント登録
- mutual_tls_sender_constrained_access_tokens
考慮事項 †
実装に関する †
Server †
- 他のクライアント認証をサポートする場合、こちらをオプションにする。
- Resource Server
クライアントの証明書のチェーンを検証する必要はないので、
証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
Access Token †
- クライアント認証なしの"送信者制限付きAccess Token"
- クライアント認証なしで、"送信者制限付きAccess Token"のみ使用できる。
- この場合、証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
- クライアント認証書とAccess Tokenから取得した証明書フィンガープリントを比較する。
- 証明書にバインドされた"送信者制限付きAccess Token"
- Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
- クライアント証明書を更新すると、"送信者制限付きAccess Token"は無効になる。
Implicit Flowはサポートされない。 †
TokenエンドポイントへTokenリクエストしないFlowはサポートできない。
セキュリティに関する †
TLS †
- バージョン
TLS 1.2 [RFC5246]
- 考慮事項
BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS
証明書スプーフィング †
- 同じサブジェクト識別名（DN）を持つ証明書を使用してクライアントを偽装しようとする可能性がある。
- 従って、証明書発行ポリシーがセキュリティ要件を満たしている限られた数のCAだけを信頼アンカーとして受け入れるべき。
OAuth 2.0 Token Bindingの
「Tokenを、Client上の非対称キー・ペアにバインドする」処理方式は、
"送信者制限付きAccess Token"に対する
に対して、幾つかの類似点がある。
類似点 †
デザイン †
- Access TokenのBindingに関して、事実上競合する仕様。
- Authorization Serverが発行したAccess Tokenを、
Client上の非対称キー・ペアにバインドする。
- Client上で生成される非対称キー・ペアを使用し、
- 秘密鍵保持の証明（Proof of Possession、POP）を行う。
モチベーション †
規制要件によって動機付けられたOAuth対応の金融取引で、
- 証明書の作成、配布、および管理の難しさの多くを回避し、
- より広範な導入と展開を見込む可能性がある。
相違点 †
まだ、新しく、現在の開発プラットフォームとツールでは、比較的少数のサポートしかない。
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens †
参考 †
Tags: :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
