Skip to content

MS_OAuthMTLS

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

概要

記名式切符作成に関するセキュリティ拡張仕様（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」で、以下を選択的に使用できる。

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

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

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

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

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

方法

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

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

公開鍵基盤（PKI）

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

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

  • メタデータ値: 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 は、「持参人切符」は取り扱ってはならない。」の
助詞の重複を「を取り扱ってはならない」に整えた。

対象のEndPoint

Authorization Server のエンドポイント

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

Resource Server のエンドポイント

任意のエンドポイント

詳細

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

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

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

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

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

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

  • 送信者制限には、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": "ty.webb@example.com",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf":{
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}
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"
  }
}

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

送信者制限のベリファイ

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

メタデータ

Discovery のメタデータ

（OpenID Connect - Discovery）

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

Dynamic Client Registration のメタデータ

（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 の双方）。

考慮事項

実装に関する考慮事項

Server の実装

  • Authorization Server

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

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

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

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

Access Token の実装

クライアント認証と "送信者制限付き 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）。

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 が中断されても良い。
    • この場合、クライアント証明書メタデータを受け渡す方法は仕様の範囲外。

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

X.509証明書と証明書チェーンの解析と検証

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

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

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

証明書スプーフィング

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

OAuth 2.0 Token Bindingとの関連

（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 の状況

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

OAuth 2.0 Mutual TLS の状況

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

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

参考

本 Wiki 内

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally