- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-戻る
-[[戻る>OAuth 2.0 拡張]]
--[[Token Binding]]
--[[Financial API (FAPI)]]
---[[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]]の作成と使用。
-Mutual TLS というと、単に「TLS 通信時にクライアント側も[[証明書]]を提示する」ことを意味する。
※ このページは、ドラフト 07 を参考にして作成。
-FAPI の文脈では、[[記名式切符>トークン#b38de47f]]の作成と使用。
--クライアント[[証明書]]による OAuth クライアント認証
--クライアント[[証明書]]に紐付くトークンに関する処理
--別称「Certificate Binding」で、以下を選択的に使用できる。
---公開鍵基盤（PKI）
---[[自己署名証明書>証明書#f729c84b]]・公開鍵（jwks_uri等）
※ このページは、ドラフト 12 を参考にして作成。
**方法 [#f7c9acb8]
-X.509証明書のクライアント証明書を使用する。~
以下のケースで処理方式が異なってくる。
--正規の[[証明書]]で、[[証明書]]チェーンとサブジェクト識別名（DN）を使用する方式
--[[自己証明書>証明書#f729c84b]]で証明書チェーンを検証しない方式
X.509[[証明書]]のクライアント[[証明書]]を使用する。
-TLSハンドシェイクにより秘密鍵の所有を検証する。
-クライアント[[証明書]]の入れ替えは自由に行うことが出来る。
-以下のケースで処理方式が異なってくる。
-Introspectionエンドポイントで関連付ける方法もあるが、~
通常は、Access Tokenを[[JWT]]にして、その中に証明書のハッシュを埋め込む。~
詳しくは、「[[バインド方式>#c70f34b9]]」を参照のこと。
***公開鍵基盤（PKI） [#q2357e5b]
-TLS 通信で用いられた公開鍵基盤（PKI）のクライアント[[証明書]]を用いる方式
--[[証明書]]チェーンと、
--事前登録したサブジェクト識別名（DN）を使用する。~
（その場合のメタデータは、tls_client_auth_subject_dn）
※ [[自己証明書>証明書#f729c84b]]＋[[JWT]]が良さそう。~
また、使用する非対称鍵（公開鍵と秘密鍵のキーペア）は、~
*.pfxをJWK化し、色々な規格と共有できそう。
-[[JWT Client Assertion>OpenID Connect#y7bdab62]]
-[[Requestオブジェクト>JWT Secured Authorization Request (JAR)]]
-メタデータ値: [[tls_client_auth>#b8351ef2]]
***[[自己署名証明書>証明書#f729c84b]] [#k39dceb1]
-TLS 通信で用いられた[[自己署名>証明書#f729c84b]]のクライアント[[証明書]]を用いる方式
--[[証明書]]チェーンを検証しない
--当該[[自己署名証明書>証明書#f729c84b]]と、
--事前登録した公開鍵（jwks_uri等）を使用する。~
（このメタデータは定義されていない）
-メタデータ値: [[self_signed_tls_client_auth>#l7d10e9d]]
**シーケンス [#wd765fc2]
***Client - Authorization Server [#g179bfa3]
***バインディング [#g179bfa3]
-Token EndpointでMutual TLSクライアント認証する。
-X.509証明書のHashによりClientとAccess Tokenを結び付ける。
-X.509[[証明書]]のHashによりClientとAccess Tokenを結び付ける。
***Client - Resource Server [#fd4e2ddf]
***ベリファイ [#fd4e2ddf]
-Resource EndPointでMutual TLSクライアント認証する。
-Resource Serverは、X.509証明書のHashと、Access Tokenの結び付けを検証する。
-Resource Serverは、X.509[[証明書]]のHashと、Access Tokenの結び付けを検証する。
**方式のメリット・デメリット [#pebae252]
***メリット [#rf81ce75]
-Client自体は殆ど何も変えなくて良い。
-対応しなければならないのはServer側。
***デメリット [#nf5f4d41]
-Client側からは、Serverがそのトークンを「持参人切符」として扱ったのか「記名式切符」として扱ったのかわからない。
-Client自身のリスク管理には、その情報が必要なので、同じリソースURIは、「持参人切符」は取り扱ってはならない。
-異なるAuthorization Schemeではなく、Bearerスキーマをそのまま使うのは、英国のOpen Bankingでの採用のしやすさに配慮した結果。
-Client側からは、Serverがそのトークンを
--「[[持参人切符>トークン#b38de47f]]」として扱ったのか
--「[[記名式切符>トークン#b38de47f]]」として扱ったのか
>解らない。
-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）：[[証明書]]内の件名情報と一致するか確認
***tls_client_auth [#b8351ef2]
tls_client_auth_subject_dn
-[IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
--PKI認証方式メタデータ値
---tls_client_auth
---クライアント認証にクライアント[[証明書]]のPKIを使用する。
--クライアント登録メタデータ
---tls_client_auth_subject_dn
---クライアント[[証明書]]の予想されるサブジェクト識別名の文字列表現。
-クライアント[[証明書]]の予想されるサブジェクト識別名の文字列表現。
※ クライアント[[証明書]]の入れ替えは自由に行うことが出来る。
***self_signed_tls_client_auth [#l7d10e9d]
（メタデータの規定は無し）
***自己署名クライアント証明書によるクライアント認証方式 [#l7d10e9d]
-[[証明書]]自体（または信頼できるソース）をAuthorization Serverに登録する方式
--公開鍵に対応する秘密鍵の所有：[[TLSハンドシェイクにより検証（設定で証明書チェーンは検証しない）>#m01d3183]]
-[[jwks_uri>OpenID Connect - 暗号関連#tdf4ee76]] の [[Jwk Set>JWK#j5494828]]から、~
x5cパラメタの最初の証明書の公開鍵~
（RSA = "n" and "e", EC = "x" and "y"）を取得。
-[IANA.OAuth.Parameters]に、次の認証方式メタデータ値を定義して登録
--自己署名[[証明書]]認証方式メタデータ値
---self_signed_tls_client_auth
---クライアント認証にクライアント[[証明書]]を使用する。
**送信者制限付きAccess Token [#f10a8615]
-送信者制限には、x5t#S256（SHA-256による[[証明書]]フィンガープリント）を使用する。
-x5t#S256は以下の様に規定されるので通常、thumbprintの文字列をそのまま扱えばイイ。
base64url-encoded [RFC4648] SHA-256 [SHS] hash
(a.k.a. thumbprint, fingerprint or digest)
of the DER encoding of the X.509 certificate [RFC5280].
--クライアント登録メタデータ~
Authorization Serverにクライアント[[証明書]]と公開鍵を送る。~
※ [[JWT Secured Authorization Request (JAR)]]と同じような方法。
---[[Jwk Set>JWK#j5494828]]
---[[jwks_uri>OpenID Connect - 暗号関連#tdf4ee76]]~
Authorization Server設定を変更せず、クライアント[[証明書]]をローテーションできる。
**送信者制限付きAccess Token [#f10a8615]
-ClientがTokenエンドポイントへの接続でクライアント[[証明書]]を使用すると、~
***バインディング [#c70f34b9]
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]]ペイロードの例。
--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エンドポイント>OAuth 2.0 Token Introspection]]から以下のような、~
x5t#S256 (SHA-256による[[証明書]]フィンガープリント)を含むメタデータを返す。
-Introspectionエンドポイント~
[[Introspectionエンドポイント>OAuth 2.0 Token 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"
}
}
***メタデータ [#t0a9806f]
-Authorization Server
--mutual_tls_sender_constrained_access_tokens
---"送信者制限付きAccess Token"のサポートを示すbool値。
---オプション。default値は "false"。
***ベリファイ [#bff5b6d1]
Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。~
（[[証明書]]が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。）
-クライアント登録
--mutual_tls_sender_constrained_access_tokens
---"送信者制限付きAccess Token"の使用する意図を示すbool値。
---オプション。default値は "false"。
**メタデータ [#t0a9806f]
***[[OpenID Connect - Discovery]] [#j3bdbbcd]
-mutual_tls_sender_constrained_access_tokens
--本仕様のサポートを示すbool値。
--オプション。default値は "false"。
***[[OpenID Connect - Dynamic Client Registration]] [#kc0dcaaf]
-mutual_tls_sender_constrained_access_tokens
--本仕様を使用する意図を示すbool値。
--オプション。default値は "false"。
*考慮事項 [#he30e6f1]
**実装に関する [#s73c2ead]
***Server [#jc54af1d]
-Authorization Server
--他のクライアント認証をサポートする場合、こちらをオプションにする。
--他のクライアント認証をサポートする場合、~
(MTLS)クライアント認証をオプションにする。
--[[自己署名クライアント証明書によるクライアント認証方式>#u145c350]]を使用する場合、~
--[[自己署名証明書>#l7d10e9d]]を使用する場合、~
[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
--他のエンドポイントのTLS挙動に対する意図しない影響を防ぐために、~
[[クライアント認証を必要としない他のエンドポイント>#x1a2f0fe]]を、~
--クライアント認証を必要としない他のエンドポイントを、~
他のホスト名でホストすることを考慮してもよい。
-Resource Server~
クライアントの[[証明書]]のチェーンを検証する必要はないので、~
Resource Serverは、クライアントの[[証明書]]のチェーンを検証する必要はないので、~
[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
***Access Token [#f1963489]
クライアント認証と"[[送信者制限付きAccess Token>#f10a8615]]"は、互いに独立して使用できる。
-クライアント認証ありの"[[送信者制限付きAccess Token>#f10a8615]]"
--これについては説明済み。
--クライアント[[証明書]]を更新すると、"[[送信者制限付きAccess Token>#f10a8615]]"は無効になる。
--無効化された場合は、期限切れのアクセストークンと同様に処理できる。
-クライアント認証なしの"[[送信者制限付きAccess Token>#f10a8615]]"
--クライアント認証なしで、"[[送信者制限付きAccess Token>#f10a8615]]"のみ使用できる。
--この場合、[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
--クライアント認証書とAccess Tokenから取得した[[証明書]]フィンガープリントを比較する。
--Tokenリクエストで、[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。
--Resourceリクエストで、クライアント認証書とAccess Tokenから取得した[[証明書]]フィンガープリントを比較する。
-[[証明書]]にバインドされた"[[送信者制限付きAccess Token>#f10a8615]]"
--Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
--クライアント[[証明書]]を更新すると、"[[送信者制限付きAccess Token>#f10a8615]]"は無効になる。
※ 互いに独立して使用できるというコトは、
--tls_client_auth
--self_signed_tls_client_auth
>をクライアント認証のみで使用することもできる？
***Implicit Flowはサポートされない。 [#w514d947]
TokenエンドポイントへTokenリクエストしないFlowはサポートできない。
-TokenエンドポイントへリクエストしないImplicit Flowはサポートできない。
-逆に、Hybrid Flowのサポートも必要だが、Tokenエンドポイントで処理しさえすればよい。
**セキュリティに関する [#q3df8e67]
***TLS [#t130de5f]
-バージョン~
TLS 1.2 [RFC5246]
-バージョン
--主流なので、TLS 1.2 [RFC5246]を引用。
--最近発表された、TLS 1.3 [RFC8446]を推奨。
-考慮事項~
BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS
-ネットワーク仲介者
--ロードバランサ、リバースプロキシなどで、TLSが中断されても良い。
--この場合、クライアント証明書メタデータを受け渡す方法は仕様の範囲外。
***X.509証明書と証明書チェーンの解析と検証 [#p32faa86]
-X.509証明書と証明書チェーンの解析と検証は複雑
-実装ミスによって以前にセキュリティの脆弱性が露呈していた。
-十分にテストされたX.509ライブラリを使用するべきで、~
独自のX.509証明書検証手順を書かないこと。
***証明書スプーフィング [#o6727a25]
-同じサブジェクト識別名（DN）を持つ[[証明書]]を使用してクライアントを偽装しようとする可能性がある。
-従って、[[証明書]]発行ポリシーがセキュリティ要件を満たしている限られた数のCAだけを信頼アンカーとして受け入れるべき。
*[[OAuth 2.0 Token Binding]]との関連 [#be4c5ae4]
**類似点 [#kee2e23b]
[[OAuth 2.0 Token Binding]]の
>「Tokenを、Client上の非対称キー・ペアにバインドする」処理方式は、
"[[送信者制限付きAccess Token>#f10a8615]]"に対する
-デザイン
-モチベーション
に対して、幾つかの類似点がある。
**類似点 [#kee2e23b]
***デザイン [#c9ad3890]
-[[記名式切符（Proof-of-possession Token）>トークン#b38de47f]]のための~
-[[記名式切符>トークン#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
-【2019年版】世界最先端の API セキュリティー技術、~
実装者による『FAPI（Financial-grade API）』解説 - Qiita~
0.2. Mutual TLS~
https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744#02-mutual-tls
-KEYCLOAK-6771 Holder of Key mechanism:~
OAuth 2.0 Mutual TLS Client Authentication and~
Certificate Bound Access Tokens by tnorimat~
Pull Request #5083 · keycloak/keycloak~
https://github.com/keycloak/keycloak/pull/5083
**[[OAuth 2.0 Token Binding]] [#c120de0e]
**[[ASP.NET＋クライアント証明書]] [#scff2aca]
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
