![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 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 -Mutual TLS というと、単に「TLS 通信時にクライアント側も[[証明書]]を提示する」ことを意味する。 -FAPI の文脈では、[[記名式切符>トークン#b38de47f]]の作成と使用。 --クライアント[[証明書]]による OAuth クライアント認証 --クライアント[[証明書]]に紐付くトークンに関する処理 --別称「Certificate Binding」で、以下を選択的に使用できる。 ---公開鍵基盤（PKI） ---[[自己署名証明書>証明書#f729c84b]]・公開鍵（jwks_uri等） ※ このページは、ドラフト 12 を参考にして作成。 **方法 [#f7c9acb8] X.509[[証明書]]のクライアント[[証明書]]を使用する。 -TLSハンドシェイクにより秘密鍵の所有を検証する。 -クライアント[[証明書]]の入れ替えは自由に行うことが出来る。 -以下のケースで処理方式が異なってくる。 ***公開鍵基盤（PKI） [#q2357e5b] -TLS 通信で用いられた公開鍵基盤（PKI）のクライアント[[証明書]]を用いる方式 --[[証明書]]チェーンと、 --事前登録したサブジェクト識別名（DN）を使用する。~ （その場合のメタデータは、tls_client_auth_subject_dn） -メタデータ値: [[tls_client_auth>#b8351ef2]] ***[[自己署名証明書>証明書#f729c84b]] [#k39dceb1] -TLS 通信で用いられた[[自己署名>証明書#f729c84b]]のクライアント[[証明書]]を用いる方式 --[[証明書]]チェーンを検証しない --当該[[自己署名証明書>証明書#f729c84b]]と、 --事前登録した公開鍵（jwks_uri等）を使用する。~ （このメタデータは定義されていない） -メタデータ値: [[self_signed_tls_client_auth>#l7d10e9d]] **シーケンス [#wd765fc2] ***バインディング [#g179bfa3] -Token EndpointでMutual TLSクライアント認証する。 -X.509[[証明書]]のHashによりClientとAccess Tokenを結び付ける。 ***ベリファイ [#fd4e2ddf] -Resource EndPointでMutual TLSクライアント認証する。 -Resource Serverは、X.509[[証明書]]のHashと、Access Tokenの結び付けを検証する。 **方式のメリット・デメリット [#pebae252] ***メリット [#rf81ce75] -Client自体は殆ど何も変えなくて良い。 -対応しなければならないのはServer側。 ***デメリット [#nf5f4d41] -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の登録方法に依存しない。 --動的に登録 --静的に構成 --別の方法で確立 ***tls_client_auth [#b8351ef2] tls_client_auth_subject_dn -クライアント[[証明書]]の予想されるサブジェクト識別名の文字列表現。 ***self_signed_tls_client_auth [#l7d10e9d] （メタデータの規定は無し） -[[jwks_uri>OpenID Connect - 暗号関連#tdf4ee76]] の [[Jwk Set>JWK#j5494828]]から、~ x5cパラメタの最初の証明書の公開鍵~ （RSA = "n" and "e", EC = "x" and "y"）を取得。 **送信者制限付き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]. ***バインディング [#c70f34b9] 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エンドポイント>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" } } ***ベリファイ [#bff5b6d1] Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。~ （[[証明書]]が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。） **メタデータ [#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)クライアント認証をオプションにする。 --[[自己署名証明書>#l7d10e9d]]を使用する場合、~ [[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。 --クライアント認証を必要としない他のエンドポイントを、~ 他のホスト名でホストすることを考慮してもよい。 -Resource Server~ Resource Serverは、クライアントの[[証明書]]のチェーンを検証する必要はないので、~ [[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。 ***Access Token [#f1963489] クライアント認証と"[[送信者制限付きAccess Token>#f10a8615]]"は、互いに独立して使用できる。 -クライアント認証ありの"[[送信者制限付きAccess Token>#f10a8615]]" --これについては説明済み。 --クライアント[[証明書]]を更新すると、"[[送信者制限付きAccess Token>#f10a8615]]"は無効になる。 --無効化された場合は、期限切れのアクセストークンと同様に処理できる。 -クライアント認証なしの"[[送信者制限付きAccess Token>#f10a8615]]" --クライアント認証なしで、"[[送信者制限付きAccess Token>#f10a8615]]"のみ使用できる。 --Tokenリクエストで、[[証明書]]チェーンを検証しないようにTLSスタックを構成する必要がある。 --Resourceリクエストで、クライアント認証書とAccess Tokenから取得した[[証明書]]フィンガープリントを比較する。 ※ 互いに独立して使用できるというコトは、 --tls_client_auth --self_signed_tls_client_auth >をクライアント認証のみで使用することもできる？ ***Implicit Flowはサポートされない。 [#w514d947] -TokenエンドポイントへリクエストしないImplicit Flowはサポートできない。 -逆に、Hybrid Flowのサポートも必要だが、Tokenエンドポイントで処理しさえすればよい。 **セキュリティに関する [#q3df8e67] ***TLS [#t130de5f] -バージョン --主流なので、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]]"に対する -デザイン -モチベーション に対して、幾つかの類似点がある。 ***デザイン [#c9ad3890] -[[記名式切符>トークン#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]]
