• 戻る
  • OAuth 2.0 拡張（OAuth2.0 Proof of Possession）
    Financial API (FAPI)（FAPI1、FAPI2）、OAuth 2.1
  • UserAgentでOAuth2のTokenを取得するベスト・プラクティス
    • OAuth2.0 mTLS（最初の派生）
    • Token Binding（廃止の傾向）
    • OAuth2.0 DPoP

記名式切符作成に関するセキュリティ拡張仕様（RFC 8705 として標準化）

• Mutual TLS(MTLS)：OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

• OAuth2.0 Proof of Possessionが前提とした（RFC 8705）の派生と言える。
  TLS 依存でインフラ構築が必要。

• Mutual TLS というと、単に「TLS 通信時にクライアント側も証明書を提示する」
  ことを意味する。

• FAPI の文脈では、記名式切符の作成と使用。

  • クライアント証明書による OAuth クライアント認証

  • クライアント証明書に紐付くトークンに関する処理

  • 別称「Certificate Binding」で、以下を選択的に使用できる。

    • 公開鍵基盤（PKI）
    • 自己署名証明書・公開鍵（jwks_uri 等）

※ このページは、ドラフト 12 を参考にして作成。

移行メモ（誤字）: 「キュリティ拡張仕様」→「セキュリティ拡張仕様」を修正した。

補足（2 つの機能が 1 つの仕様に入っている）: 名称が長いのは、
この仕様が独立して使える 2 つの機能を含むためである。

1. Mutual TLS Client Authentication
   … クライアント証明書を client_secret の代わりに使う（クライアント認証）
2. Certificate Bound Access Tokens
   … 発行するアクセス トークンをその証明書に紐づける（送信者制約）

後述の「実装に関する ---> Access Token」にあるとおり、
この 2 つは互いに独立して使用できる。

X.509 証明書のクライアント証明書を使用する。

• TLS ハンドシェイクにより秘密鍵の所有を検証する。
• クライアント証明書の入れ替えは自由に行うことが出来る。
• 以下のケースで処理方式が異なってくる。

• TLS 通信で用いられた公開鍵基盤（PKI）のクライアント証明書を用いる方式

  • 証明書チェーンと、
  • 事前登録したサブジェクト識別名（DN）を使用する。
    （その場合のメタデータは、tls_client_auth_subject_dn）

• メタデータ値: tls_client_auth

• TLS 通信で用いられた自己署名のクライアント証明書を用いる方式

  • 証明書チェーンを検証しない
  • 当該自己署名証明書と、
  • 事前登録した公開鍵（jwks_uri 等）を使用する。
    （このメタデータは定義されていない）

• メタデータ値: self_signed_tls_client_auth

補足（どちらを選ぶか）: PKI 方式は
CA が証明書を再発行しても登録内容を変えずに済む（DN で照合するため）が、
信頼する CA の管理が必要になる。
自己署名方式は CA が不要で、鍵のローテーションを
jwks_uri の更新だけで行える。
FAPI では両方が認められている。

• 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 での採用のし易さに配慮した結果。

移行メモ（助詞）: 「同じリソース URI は、「持参人切符」は取り扱ってはならない。」の
助詞の重複を「を取り扱ってはならない」に整えた。

Authorization Server の下記のエンドポイントにクライアント認証の追加メカニズムを提供。

• RFC6749 ... OAuth 2.0 : Token エンドポイント
• RFC 7009 ... Token Revocation : Revocation エンドポイント
• RFC 7662 ... Token Introspection : Introspection エンドポイント

任意のエンドポイント

• client_id パラメタが必須
  クライアント証明書の内容とは独立して Client を識別するため。

• クライアント証明書を Client Credentials として使用して、
  client_id をバインドする 2 つの異なった方法がある。

• なお、Client の登録方法に依存しない。

  • 動的に登録
  • 静的に構成
  • 別の方法で確立

tls_client_auth_subject_dn

• クライアント証明書の予想されるサブジェクト識別名の文字列表現。

（メタデータの規定は無し）

• jwks_uri の Jwk Setから、
  x5c パラメタの最初の証明書の公開鍵
  （RSA = "n" and "e", EC = "x" and "y"）を取得。

• 送信者制限には、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].

Client が Token エンドポイントへの接続でクライアント証明書を使用すると、
Authorization Server は発行された Access Token をクライアント証明書に
バインドできる。

• Access Token に証明書ハッシュを埋め込む
  • JWT に、cnf > x5t#S256 メンバとして埋め込む。
  • 以下は、x5t#S256 を含む JWT ペイロードの例。

{
  "iss": "https://server.example.com",
  "sub": "[email protected]",
  "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": "[email protected]",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf":{
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

補足（cnf クレーム）: cnf（confirmation）は RFC 7800 で定義された
「このトークンを使うには、ここに書かれた鍵の所有を証明せよ」という
汎用のクレームである。
mTLS は cnf の中に証明書のフィンガープリント（x5t#S256）を入れ、
DPoP は公開鍵のサムプリント（jkt）を入れる。
記名式切符の「記名欄」にあたる。

Client は、Resource リクエストに、Token リクエストで使用したクライアント認証を
使用する必要がある。
（証明書が一致しない場合は、HTTP 401 と "invalid_token" で拒否が必須。）

（OpenID Connect - Discovery）

• mutual_tls_sender_constrained_access_tokens
  • 本仕様のサポートを示す bool 値。
  • オプション。default 値は "false"。

（OpenID Connect - Dynamic Client Registration）

• mutual_tls_sender_constrained_access_tokens
  • 本仕様を使用する意図を示す bool 値。
  • オプション。default 値は "false"。

移行メモ（RFC でのパラメタ名）: 本ページはドラフト 12 を基にしているため
mutual_tls_sender_constrained_access_tokens となっているが、
RFC 8705 では tls_client_certificate_bound_access_tokens に改称された
（Discovery / Registration の双方）。

• Authorization Server

  • 他のクライアント認証をサポートする場合、
    (MTLS) クライアント認証をオプションにする。

  • 自己署名証明書を使用する場合、
    証明書チェーンを検証しないように TLS スタックを構成する必要がある。

  • クライアント認証を必要としない他のエンドポイントを、
    他のホスト名でホストすることを考慮してもよい。

• Resource Server
  Resource Server は、クライアントの証明書のチェーンを検証する必要はないので、
  証明書チェーンを検証しないように TLS スタックを構成する必要がある。

クライアント認証と "送信者制限付き Access Token" は、
互いに独立して使用できる。

• クライアント認証ありの "送信者制限付き Access Token"

  • これについては説明済み。
  • クライアント証明書を更新すると、
    "送信者制限付き Access Token" は無効になる。
  • 無効化された場合は、期限切れのアクセストークンと同様に処理できる。

• クライアント認証なしの "送信者制限付き Access Token"

  • クライアント認証なしで、
    "送信者制限付き Access Token" のみ使用できる。
  • Token リクエストで、証明書チェーンを検証しないように
    TLS スタックを構成する必要がある。
  • Resource リクエストで、クライアント認証書と Access Token から取得した
    証明書フィンガープリントを比較する。

※ 互いに独立して使用できるというコトは、

• tls_client_auth
• self_signed_tls_client_auth

をクライアント認証のみで使用することもできる？

補足（上記の疑問への答え）: そのとおりで、
クライアント認証だけに使うことができる。
RFC 8705 では、クライアント認証（第 2 章）と
証明書バインド アクセス トークン（第 3 章）が
明確に別の章立てになっており、
Discovery / Registration のメタデータも別々に用意されている
（前者は token_endpoint_auth_method、
後者は tls_client_certificate_bound_access_tokens）。

• Token エンドポイントへリクエストしない Implicit Flow はサポートできない。
• 逆に、Hybrid Flow のサポートも必要だが、Token エンドポイントで処理しさえすればよい。

• バージョン

  • 主流なので、TLS 1.2 [RFC5246] を引用。
  • 最近発表された、TLS 1.3 [RFC8446] を推奨。

• 考慮事項
  BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS

• ネットワーク仲介者

  • ロードバランサ、リバースプロキシなどで、TLS が中断されても良い。
  • この場合、クライアント証明書メタデータを受け渡す方法は仕様の範囲外。

補足（TLS 終端が最大の実装課題）: 「TLS が中断されても良い」とあるが、
その場合ロードバランサが受け取ったクライアント証明書を
アプリケーションまで運ぶ必要がある（X-SSL-Client-Cert 等のヘッダ）。
仕様外なので製品ごとに作法が異なり、
かつ外部から同じヘッダを偽装されないよう必ず上書きする必要がある。
mTLS の導入で「インフラ構築が必要」と言われる実体は、ここにある。

• X.509 証明書と証明書チェーンの解析と検証は複雑

• 実装ミスによって以前にセキュリティの脆弱性が露呈していた。

• 十分にテストされた X.509 ライブラリを使用するべきで、
  独自の X.509 証明書検証手順を書かないこと。

• 同じサブジェクト識別名（DN）を持つ証明書を使用して
  クライアントを偽装しようとする可能性がある。
• 従って、証明書発行ポリシーがセキュリティ要件を満たしている
  限られた数の CA だけを信頼アンカーとして受け入れるべき。

（OAuth 2.0 Token Binding）

OAuth 2.0 Token Binding の

「Token を、Client 上の非対称キー・ペアにバインドする」処理方式は、

"送信者制限付き Access Token" に対する

• デザイン
• モチベーション

に対して、幾つかの類似点がある。

• 記名式切符のための
  紐付け（トークン・バインディング）に関して、
  OAuth 2.0 Token Binding と競合する仕様。

• Authorization Server が発行した Access Token を、
  Client 上の非対称キー・ペアにバインドする。

  • Client 上で生成される非対称キー・ペアを使用し、
  • 秘密鍵保持の証明（Proof of Possession、POP）を行う。

規制要件によって動機付けられた OAuth 対応の金融取引で、

• 証明書の作成、配布、および管理の難しさの多くを回避し、
• より広範な導入と展開を見込む可能性がある。

まだ、新しく、現在の開発プラットフォームとツールでは、比較的少数のサポートしかない。

• しばらく前からあり、現在の開発プラットフォームとツールで広くサポートされている。
• こちらは、OAuth 2.0 Token Binding より、迅速なソリューション提供を目指している。

補足（決着）: この比較の結論は、
mTLS が RFC 8705 として標準化され、Token Binding は
ブラウザ実装が見送られて事実上廃止、という形で出た。
「証明書の作成・配布・管理の難しさを回避したい」という
Token Binding のモチベーションのほうは、その後
**アプリケーション層で鍵を持つ DPoP（RFC 9449）**が
引き受けている。
FAPI 2.0 でも、送信者制約の手段として
mTLS または DPoP が指定されている。

• 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

• OAuth2.0 Proof of Possession
• OAuth2.0 DPoP
• Token Binding
• ASP.NET＋クライアント証明書
• Financial API (FAPI)

Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth