「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Mutual TLS(MTLS) :
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
※ このページは、ドラフト 07 を参考にして作成。
方法 †
- X.509証明書のクライアント証明書を使用する。
以下のケースで処理方式が異なってくる。
- 正規の証明書で、証明書チェーンとサブジェクト識別名（DN）を使用する方式
- 自己証明書で証明書チェーンを検証しない方式
- Introspectionエンドポイントで関連付ける方法もあるが、
通常は、Access TokenをJWTにして、その中に証明書のハッシュを埋め込む。
詳しくは、「バインド方式」を参照のこと。
※ 自己証明書＋JWTが良さそう。
また、使用する非対称鍵（公開鍵と秘密鍵のキーペア）は、*.pfxをJWK化し、色々な規格と共有できそう。
シーケンス †
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の結び付けを検証する。
方式のメリット・デメリット †
メリット †
- Client自体は殆ど何も変えなくて良い。
- 対応しなければならないのはServer側。
デメリット †
- Client側からは、Serverがそのトークンを「持参人切符」として扱ったのか「記名式切符」として扱ったのかわからない。
- Client自身のリスク管理には、その情報が必要なので、同じリソースURIは、「持参人切符」は取り扱ってはならない。
- 異なるAuthorization Schemeではなく、Bearerスキーマをそのまま使うのは、英国のOpen Bankingでの採用のしやすさに配慮した結果。
対象のEndPoint? †
Authorization Server †
Authorization Serverの下記のエンドポイントにクライアント認証の追加メカニズムを提供。
Resource 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
- "送信者制限付きAccess Token"のサポートを示すbool値。
- オプション。default値は "false"。
- クライアント登録
- mutual_tls_sender_constrained_access_tokens
- "送信者制限付きAccess Token"の使用する意図を示すbool値。
- オプション。default値は "false"。
考慮事項 †
実装に関する †
Server †
- 他のクライアント認証をサポートする場合、こちらをオプションにする。
- Resource Server
クライアントの証明書のチェーンを検証する必要はないので、
証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
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"に対する
に対して、幾つかの類似点がある。
類似点 †
デザイン †
- Authorization Serverが発行したAccess Tokenを、
Client上の非対称キー・ペアにバインドする。
- Client上で生成される非対称キー・ペアを使用し、
- 秘密鍵保持の証明（Proof of Possession、POP）を行う。
モチベーション †
規制要件によって動機付けられたOAuth対応の金融取引で、
- 証明書の作成、配布、および管理の難しさの多くを回避し、
- より広範な導入と展開を見込む可能性がある。
相違点 †
まだ、新しく、現在の開発プラットフォームとツールでは、比較的少数のサポートしかない。
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens †
参考 †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
