- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>JWTとOAuth2.0#xc8de804]]
-戻る
--[[JWTとOAuth2.0 > OAuth 2.0 拡張 > Token Binding>JWTとOAuth2.0#xc8de804]]
--[[FAPI Part 1 (Read Only API Security Profile)]]
--[[FAPI Part 2 (Read and Write API Security Profile)]]
* 目次 [#r16628e8]
#contents
*概要 [#v3994b97]
-Mutual TLS(MTLS) :~
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
-[[記名式切符（Proof-of-possession Token）>トークン#b38de47f]]の作成と使用。
※ このページは、ドラフト 07 を参考にして作成。
**方法 [#f7c9acb8]
-X.509証明書のクライアント証明書を使用する。~
以下のケースで処理方式が異なってくる。
--正規の[[証明書]]で、[[証明書]]チェーンとサブジェクト識別名（DN）を使用する方式
--[[自己証明書>証明書#f729c84b]]で証明書チェーンを検証しない方式
-Introspectionエンドポイントで関連付ける方法もあるが、~
通常は、Access Tokenを[[JWT]]にして、その中に証明書のハッシュを埋め込む。~
詳しくは、「[[バインド方式>#c70f34b9]]」を参照のこと。
※ [[自己証明書>証明書#f729c84b]]＋[[JWT]]が良さそう。~
また、使用する非対称鍵（公開鍵と秘密鍵のキーペア）は、*.pfxをJWK化し、色々な規格と共有できそう。
-[[JWT Client Assertion>OpenID Connect#y7bdab62]]
-[[Requestオブジェクト>JWT Secured Authorization Request (JAR)]]
**シーケンス [#wd765fc2]
***Client - Authorization Server [#g179bfa3]
-Token EndpointでMutual TLSクライアント認証する。
-X.509証明書のHashによりClientとAccess Tokenを結び付ける。
***Client - Resource Server [#fd4e2ddf]
-Resource EndPointでMutual TLSクライアント認証する。
-Resource Serverは、X.509証明書のHashと、Access Tokenの結び付けを検証する。
**方法 [#f7c9acb8]
任意だが、Access Tokenを[[JWT]]にして、その中に証明書のハッシュを埋め込む。
**方式のメリット・デメリット [#pebae252]
**メリット・デメリット [#pebae252]
***メリット [#rf81ce75]
-Client自体は殆ど何も変えなくて良い。
-対応しなければならないのはServer側。
***デメリット [#nf5f4d41]
-Client側からは、Serverがそのトークンを「持参人切符」として扱ったのか「記名式切符」として扱ったのかわからない。
-Client自身のリスク管理には、その情報が必要なので、同じリソースURIは、「持参人切符」は取り扱ってはならない。
-異なるAuthorization Schemeではなく、Bearerスキーマをそのまま使うのは、英国のOpen Bankingでの採用のしやすさに配慮した結果。
**対象のEndPoint [#v33211a0]
***Authorization Server [#y2ee1c1f]
Authorization Serverの下記のエンドポイントにクライアント認証の追加メカニズムを提供。
-[[RFC6749 ... OAuth 2.0>OAuth]] : Tokenエンドポイント
-[[RFC 7009 ... Token Revocation>OAuth 2.0 Token Revocation]] : Revocationエンドポイント
-[[RFC 7662 ... Token Introspection>OAuth 2.0 Token Introspection]] : Introspectionエンドポイント
***Resource Server [#kff691c3]
・・・
*詳細 [#f5c02b05]
**クライアント証明書によるクライアント認証 [#g58f6a38]
-client_idパラメタが必須~
クライアント[[証明書]]の内容とは独立してClientを識別するため。
-クライアント[[証明書]]をClient Credentialsとして使用して、~
client_idをバインドする2つの異なった方法がある。
-なお、Clientの登録方法に依存しない。
--動的に登録
--静的に構成
--別の方法で確立
***クライアント証明書のPKIによる認証方式 [#b8351ef2]
-[[証明書]]チェーンとサブジェクト識別名（DN）を使用する方式
--[[証明書]]チェーンの検証：TLSハンドシェイクにより公開鍵に対応する秘密鍵の所有を検証する。
--サブジェクト識別名（DN）：[[証明書]]内の件名情報と一致するか確認
-[IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
--PKI認証方式メタデータ値
---tls_client_auth
---クライアント認証にクライアント[[証明書]]のPKIを使用する。
--クライアント登録メタデータ
---tls_client_auth_subject_dn
---クライアント[[証明書]]の予想されるサブジェクト識別名の文字列表現。
※ クライアント[[証明書]]の入れ替えは自由に行うことが出来る。
***自己署名クライアント証明書によるクライアント認証方式 [#l7d10e9d]
-[[証明書]]自体（または信頼できるソース）をAuthorization Serverに登録する方式
--公開鍵に対応する秘密鍵の所有：[[TLSハンドシェイクにより検証（設定で証明書チェーンは検証しない）>#m01d3183]]
-[IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
--自己署名[[証明書]]認証方式メタデータ値
---self_signed_tls_client_auth
---クライアント認証にクライアント[[証明書]]を使用する。
--クライアント登録メタデータ~
Authorization Serverにクライアント[[証明書]]と公開鍵を送る。~
※ [[JWT Secured Authorization Request (JAR)]]と同じような方法。
---jwks_uri~
---[[Jwk Set>JWK#j5494828]]
---[[jwks_uri>OpenID Connect - 暗号関連#tdf4ee76]]~
Authorization Server設定を変更せず、クライアント[[証明書]]をローテーションできる。
---jwksメタデータ
**送信者制限付きAccess Token [#f10a8615]
-ClientがTokenエンドポイントへの接続でクライアント[[証明書]]を使用すると、~
Authorization Serverは発行されたAccess Tokenをクライアント[[証明書]]にバインドできる。
-Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。~
（[[証明書]]が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。）
-なお、[IANA.JWT.Claims] for JWT "cnf"メンバー値は[RFC7800]によって確立されている。
***バインド方式 [#c70f34b9]
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エンドポイント>OAuth 2.0 Token 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"
}
}
***メタデータ [#t0a9806f]
-Authorization Server
--mutual_tls_sender_constrained_access_tokens
---"[[送信者制限付きAccess Token>#s9ea9a32]]"のサポートを示すbool値。
---"送信者制限付きAccess Token"のサポートを示すbool値。
---オプション。default値は "false"。
-クライアント登録
--mutual_tls_sender_constrained_access_tokens
---"[[送信者制限付きAccess Token>#s9ea9a32]]"の使用する意図を示すbool値。
---"送信者制限付きAccess Token"の使用する意図を示すbool値。
---オプション。default値は "false"。
*考慮事項 [#he30e6f1]
**実装に関する [#s73c2ead]
***Server [#jc54af1d]
-Authorization Server
--他のクライアント認証をサポートする場合、こちらをオプションにする。
--[[自己署名クライアント証明書によるクライアント認証方式>#u145c350]]を使用する場合、~
[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
--他のエンドポイントのTLS挙動に対する意図しない影響を防ぐために、~
[[クライアント認証を必要としない他のエンドポイント>#x1a2f0fe]]を、~
他のホスト名でホストすることを考慮してもよい。
-Resource Server~
クライアントの[[証明書]]のチェーンを検証する必要はないので、~
[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
***Access Token [#f1963489]
-クライアント認証なしの"送信者制限付きAccess Token"
--クライアント認証なしで、"送信者制限付きAccess Token"のみ使用できる。
-クライアント認証なしの"[[送信者制限付きAccess Token>#f10a8615]]"
--クライアント認証なしで、"[[送信者制限付きAccess Token>#f10a8615]]"のみ使用できる。
--この場合、[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
--クライアント認証書とAccess Tokenから取得した[[証明書]]フィンガープリントを比較する。
-[[証明書]]にバインドされた"送信者制限付きAccess Token"
-[[証明書]]にバインドされた"[[送信者制限付きAccess Token>#f10a8615]]"
--Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
--クライアント[[証明書]]を更新すると、"送信者制限付きAccess Token"は無効になる。
--クライアント[[証明書]]を更新すると、"[[送信者制限付きAccess Token>#f10a8615]]"は無効になる。
***Implicit Flowはサポートされない。 [#w514d947]
TokenエンドポイントへTokenリクエストしないFlowはサポートできない。
**セキュリティに関する [#q3df8e67]
***TLS [#t130de5f]
-バージョン~
TLS 1.2 [RFC5246]
-考慮事項~
BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS
***証明書スプーフィング [#o6727a25]
-同じサブジェクト識別名（DN）を持つ[[証明書]]を使用してクライアントを偽装しようとする可能性がある。
-従って、[[証明書]]発行ポリシーがセキュリティ要件を満たしている限られた数のCAだけを信頼アンカーとして受け入れるべき。
*[[OAuth 2.0 Token Binding]]との関連 [#be4c5ae4]
[[OAuth 2.0 Token Binding]]の
>「Tokenを、Client上の非対称キー・ペアにバインドする」処理方式は、
"[[送信者制限付きAccess Token>#s9ea9a32]]"に対する
"[[送信者制限付きAccess Token>#f10a8615]]"に対する
-デザイン
-モチベーション
に対して、幾つかの類似点がある。
**類似点 [#kee2e23b]
***デザイン [#c9ad3890]
-Access TokenのBindingに関して、事実上競合する仕様。
-[[記名式切符（Proof-of-possession Token）>トークン#b38de47f]]のための~
紐付け（トークン・バインディング）に関して、~
[[OAuth 2.0 Token Binding]]と競合する仕様。~
-Authorization Serverが発行したAccess Tokenを、~
Client上の非対称キー・ペアにバインドする。
--Client上で生成される非対称キー・ペアを使用し、
--秘密鍵保持の証明（Proof of Possession、POP）を行う。
***モチベーション [#y7141347]
規制要件によって動機付けられたOAuth対応の金融取引で、
-証明書の作成、配布、および管理の難しさの多くを回避し、
-より広範な導入と展開を見込む可能性がある。
**相違点 [#k9e32e30]
***[[OAuth 2.0 Token Binding>OAuth 2.0 Token Binding#pe0549d8]] [#d72b2941]
まだ、新しく、現在の開発プラットフォームとツールでは、比較的少数のサポートしかない。
***OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [#e127b5ee]
-しばらく前からあり、現在の開発プラットフォームとツールで広くサポートされている。
-こちらは、[[OAuth 2.0 Token Binding>#u8785665]]より、迅速なソリューション提供を目指している。
*参考 [#i6250624]
-draft-ietf-oauth-mtls-xx - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens~
https://tools.ietf.org/html/draft-ietf-oauth-mtls
**[[OAuth 2.0 Token Binding]] [#c120de0e]
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
