-
Meetecho: https://play.conf.meetecho.com/Playout/?session=IETF103-TOKBIND-20181106-0900
-
基本3文書はRFCになった
-
TLS 1.3 → WGLCの準備OK
-
0-RTT
- 0-RTTとToken Bindingについてはこれまで何も言われていなかった。リプレイ攻撃に対して何もできない。0-RTTではToken Bindingを使わないことを推奨
- WGアイテムとする必要はない。0-RTTについてはcharterにも入っていないし
-
TTRP (TLS Terminating Reverse Proxy)
- TTRPで受け、検証済のTB Messageをバックエンドに送るためのヘッダ名と値を標準化
- proxyは、それらのヘッダがもしクライアントから送られてきたら、サニタイズしなければならない
- token bindingをサポートしないRPもサイタイズは行う必要がある
-
「メジャーなブラウザがToken Bindingのサポートをやめた」という言及があったが詳細不明
-
全体として、tokbind WGは完了に近い。IETF104ではミーティングなしの方向
-
Meetecho: https://play.conf.meetecho.com/Playout/?session=IETF103-OAUTH-20181105-0900
-
OAuth ユースケースにおける Token Bindingの利用方法
- draft-ietf-oauth-token-binding
- https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
- access token
- Referred Token Binding IDを使用
- アクセストークンがJWTの場合、およびintrospectionの戻り値では "cnf" 内の "tbh" にToken Binding IDのhashを入れることで検証可能
- refresh token
- Provided Token Binding IDを使う。かんたん
- authorization code
- PKCEを使用
-
残った問題: Implicit flowでのaccess tokenのbinding
- ややこしい。これ本当に必要なのか? ↑のスライドの6ページ
- ブラウザ内で動作するJSアプリ(クライアントドメイン)が、リソースサーバー行きのTBIDをreferred TBIDとして認証サーバーに送る必要がある
- ひとつの方法はリソースサーバーからのリダイレクトをしてもらい、Include-Referred-Token-Binding-IDヘッダをつけてもらう
- これにはフルページリダイレクトが発生するので、JSだけでページ遷移しないアプリ(SPA)では使えない
- SPAが自主的に渡すことはできない
- クライアントドメインのJSがリソースサーバードメインのTBIDを認証サーバードメインに送信するのはsame-origin policyに反する