「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Mutual TLS(MTLS) :
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
- Mutual TLS というと、単に「TLS 通信時にクライアント側も証明書を提示する」ことを意味する。
- FAPI の文脈では、記名式切符の作成と使用。
- クライアント証明書による OAuth クライアント認証
- クライアント証明書に紐付くトークンに関する処理
- 別称「Certificate Binding」で、以下を選択的に使用できる。
※ このページは、ドラフト 12 を参考にして作成。
方法 †
X.509証明書のクライアント証明書を使用する。
- TLSハンドシェイクにより秘密鍵の所有を検証する。
- クライアント証明書の入れ替えは自由に行うことが出来る。
- 以下のケースで処理方式が異なってくる。
公開鍵基盤（PKI） †
- TLS 通信で用いられた公開鍵基盤（PKI）のクライアント証明書を用いる方式
- 証明書チェーンと、
- 事前登録したサブジェクト識別名（DN）を使用する。
（その場合のメタデータは、tls_client_auth_subject_dn）
- TLS 通信で用いられた自己署名のクライアント証明書を用いる方式
- 証明書チェーンを検証しない
- 当該自己署名証明書と、
- 事前登録した公開鍵（jwks_uri等）を使用する。
（このメタデータは定義されていない）
シーケンス †
バインディング †
- Token EndpointでMutual TLSクライアント認証する。
- X.509証明書のHashによりClientとAccess Tokenを結び付ける。
ベリファイ †
- 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つの異なった方法がある。
tls_client_auth †
tls_client_auth_subject_dn
- クライアント証明書の予想されるサブジェクト識別名の文字列表現。
self_signed_tls_client_auth †
（メタデータの規定は無し）
- jwks_uri の Jwk Setから、
x5cパラメタの最初の証明書の公開鍵
（RSA = "n" and "e", EC = "x" and "y"）を取得。
送信者制限付きAccess Token †
バインディング †
ClientがTokenエンドポイントへの接続でクライアント証明書を使用すると、
Authorization Serverは発行されたAccess Tokenをクライアント証明書にバインドできる。
- Access Tokenに証明書ハッシュを埋め込む
- JWTに、cnf > x5t#S256 メンバとして埋め込む。
- 以下は、x5t#S256を含む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を含むメタデータを返す。
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"
}
}
ベリファイ †
Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
（証明書が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。）
メタデータ †
- mutual_tls_sender_constrained_access_tokens
- 本仕様のサポートを示すbool値。
- オプション。default値は "false"。
- mutual_tls_sender_constrained_access_tokens
- 本仕様を使用する意図を示すbool値。
- オプション。default値は "false"。
考慮事項 †
実装に関する †
Server †
- 他のクライアント認証をサポートする場合、
(MTLS)クライアント認証をオプションにする。
- 自己署名証明書を使用する場合、
証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
- クライアント認証を必要としない他のエンドポイントを、
他のホスト名でホストすることを考慮してもよい。
- Resource Server
Resource Serverは、クライアントの証明書のチェーンを検証する必要はないので、
証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
Access Token †
クライアント認証と"送信者制限付きAccess Token"は、互いに独立して使用できる。
※ 互いに独立して使用できるというコトは、
- tls_client_auth
- self_signed_tls_client_auth
をクライアント認証のみで使用することもできる？
Implicit Flowはサポートされない。 †
- TokenエンドポイントへリクエストしないImplicit Flowはサポートできない。
- 逆に、Hybrid Flowのサポートも必要だが、Tokenエンドポイントで処理しさえすればよい。
セキュリティに関する †
TLS †
- バージョン
- 主流なので、TLS 1.2 [RFC5246]を引用。
- 最近発表された、TLS 1.3 [RFC8446]を推奨。
- 考慮事項
BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS
- ネットワーク仲介者
- ロードバランサ、リバースプロキシなどで、TLSが中断されても良い。
- この場合、クライアント証明書メタデータを受け渡す方法は仕様の範囲外。
X.509証明書と証明書チェーンの解析と検証 †
- X.509証明書と証明書チェーンの解析と検証は複雑
- 実装ミスによって以前にセキュリティの脆弱性が露呈していた。
- 十分にテストされたX.509ライブラリを使用するべきで、
独自のX.509証明書検証手順を書かないこと。
証明書スプーフィング †
- 同じサブジェクト識別名（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]")
