-
Notifications
You must be signed in to change notification settings - Fork 0
MS_TokenBinding
- 戻る(OAuth 2.0 拡張、Financial API (FAPI)、OAuth 2.1)
- OAuth2.0 mTLS(最初の派生)
- Token Binding(廃止の傾向)
- OAuth2.0 DPoP
記名式切符(トークン)作成に関する仕様:
mTLS と同じ TLS 依存だが、コチラはブラウザが対応しインフラ構築不要の予定だったが
ブラウザ対応が頓挫し廃止。
- Token Binding(コア仕様)とは TLS セッションから派生した鍵に
トークンを紐付ける仕組み。 - TLS のブラウザ・サポートが必須であり、実装をブラウザ・ベンダに期待していた。
- 現在では廃止となり、よりアプリ層で完結できる
OAuth2.0 DPoPによって代替された。
- TLS ハンドシェイク時にクライアントが鍵ペアを生成
- TLS セッション固有の「Token Binding ID」を導出
- すべてのトークン(Cookie, OAuth token 等)をこの ID に束縛
補足(狙いは良かった): Token Binding の設計思想は優れていた。
内容 対象が広い OAuth トークンだけでなく Cookie も縛れる 透過的 ブラウザが自動でやるので、アプリ側の実装がほぼ不要 証明書不要 mTLS と違い PKI の構築が要らない 特に「Cookie を縛れる」点は大きく、
セッション ハイジャックそのものを無効化できた。
盗んだ Cookie を別端末で使っても、TLS 鍵が違うので通らない。それだけに、ブラウザ側の不採用で頓挫したのは惜しまれる。
2018年10月初旬に Token Binding 関連 RFC × 3 がリリースされた。
| RFC | 内容 |
|---|---|
| RFC 8471 | Token Binding Protocol 本体(鍵導出・証明の方法) |
| RFC 8472 | TLS 拡張(TLS ハンドシェイクへの組み込み方) |
| RFC 8473 | HTTP 上での運搬方法(Sec-Token-Binding ヘッダー) |
ドラフトの作成段階では、比較的少数のサポートしかなかった
(TLS スタックなどインフラレイヤの変更を伴い、
アプリケーションレイヤだけで解決できない)。
- Microsoft と Google が中心となり、IETF に提案
- TLS ハンドシェイク時にクライアントが鍵ペアを生成し、
サーバーにバインドするという概念が登場 - RFC 草案(
draft-ietf-tokbind-*)シリーズとして議論開始
- Google Chrome がサポート(フラグ付き)
- Microsoft Edge も Windows 環境で実装
- しかし、Firefox は実装せず
Chrome が HTTP/3・QUIC との互換性問題などを理由に実装を削除。
コミュニティから強く要望されたにも関わらず。
※ 背景:実装コストの高さ、ベンダー合意の欠如、代替技術の台頭
補足(QUIC との相性が致命的だった): Token Binding は
TLS セッションから鍵を導出する仕組みであり、
TLS のレイヤに深く依存していた。
TLS over TCP QUIC (HTTP/3) TLS の位置 TCP の上の独立した層 トランスポートに統合されている セッションの概念 明確 接続移行(Connection Migration)で変わりうる HTTP/3 への移行が進む中で、
「TLS セッションに紐づける」という前提自体が
維持しにくくなった。
これが、後継の DPoPが
アプリケーション層だけで完結する設計を選んだ理由でもある。
- ブラウザ・ベンダー間での合意が得られず、広範な普及には至らず
- IETF の Token Binding WG がクローズ、仕様ごと事実上廃止
Consumer Data Right Security Profile(オーストラリア)では次のとおり。
- MTLS MUST be supported as a Holder of Key (HoK) Mechanism.
(MTLS は、鍵保有者(HoK)メカニズムとしてサポートされなければならない)- OAUTB SHALL NOT be supported due to a lack industry support.
(OAUTB は、業界でのサポートが不足しているため、サポートされない)
移行メモ(誤字): 元ページの「コミュニテイ」「不参加代替技術」は、
それぞれ「コミュニティ」「代替技術」の誤記と解される。
上記は整えて記載した。
補足(現在の記名式トークンの選択肢): Token Binding が抜けた結果、
選択肢は次の 2 つに絞られた。
方式 RFC 依存 向く場面 mTLS RFC 8705 クライアント証明書(PKI) サーバー間。金融の基幹連携 DPoP RFC 9449 アプリ層のみ SPA / モバイル / CLI FAPI 2.0 では両方が認められている。
証明書の配布・失効・更新という運用負荷を負えるなら mTLS、
負えないなら DPoP、という判断になる。なお、Token Binding が担うはずだった
**「Cookie を縛る」**という役割については、
現在はSameSite属性(SameSite属性)や
Device Bound Session Credentials(Google が提案中)といった
別の系統で議論が続いている。
-
RFC 8471 - The Token Binding Protocol Version 1.0
https://datatracker.ietf.org/doc/html/rfc8471 -
RFC 8472 - TLS Extension for Token Binding Protocol Negotiation
https://datatracker.ietf.org/doc/html/rfc8472 -
RFC 8473 - Token Binding over HTTP
https://datatracker.ietf.org/doc/html/rfc8473 -
Chrome は Token Binding サポート中止を決定
https://www.chromestatus.com/feature/5097603234529280 -
11.3. Holder of Key Mechanism – Consumer Data Right Security Profile
https://consumerdatastandardsaustralia.github.io/infosec/
Tags: 移行, IT国際標準, 認証基盤, ASP.NET Identity, OAuth
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。