Skip to content

MS_TokenBinding

nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Token Binding

概要

記名式切符(トークン)作成に関する仕様:
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 鍵が違うので通らない。

それだけに、ブラウザ側の不採用で頓挫したのは惜しまれる。

3本柱

2018年10月初旬に Token Binding 関連 RFC × 3 がリリースされた。

RFC 内容
RFC 8471 Token Binding Protocol 本体(鍵導出・証明の方法)
RFC 8472 TLS 拡張(TLS ハンドシェイクへの組み込み方)
RFC 8473 HTTP 上での運搬方法(Sec-Token-Binding ヘッダー)

廃止までの流れ

ドラフトの作成段階では、比較的少数のサポートしかなかった
(TLS スタックなどインフラレイヤの変更を伴い、
アプリケーションレイヤだけで解決できない)。

2015年頃 — 提案・草案

  • Microsoft と Google が中心となり、IETF に提案
  • TLS ハンドシェイク時にクライアントが鍵ペアを生成し、
    サーバーにバインドするという概念が登場
  • RFC 草案(draft-ietf-tokbind-*)シリーズとして議論開始

2019〜2020年 — ブラウザ実装

  • Google Chrome がサポート(フラグ付き)
  • Microsoft Edge も Windows 環境で実装
  • しかし、Firefox は実装せず

Chromeがサポートを中止

Chrome が HTTP/3・QUIC との互換性問題などを理由に実装を削除。
コミュニティから強く要望されたにも関わらず。

※ 背景:実装コストの高さ、ベンダー合意の欠如、代替技術の台頭

補足(QUIC との相性が致命的だった): Token Binding は
TLS セッションから鍵を導出する仕組みであり、
TLS のレイヤに深く依存していた。

TLS over TCP QUIC (HTTP/3)
TLS の位置 TCP の上の独立した層 トランスポートに統合されている
セッションの概念 明確 接続移行(Connection Migration)で変わりうる

HTTP/3 への移行が進む中で、
「TLS セッションに紐づける」という前提自体が
維持しにくくなった。
これが、後継の DPoP
アプリケーション層だけで完結する設計を選んだ理由でもある。

事実上の撤退(2021〜2022年)

  • ブラウザ・ベンダー間での合意が得られず、広範な普及には至らず
  • IETF の Token Binding WG がクローズ、仕様ごと事実上廃止

CDR では利用禁止

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 が提案中)といった
別の系統で議論が続いている。

参考

関連


Tags: 移行, IT国際標準, 認証基盤, ASP.NET Identity, OAuth

NetDevInfraWiki

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

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally