MS_OAuthPoP - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

OAuth2.0 Proof of Possession

概要

FAPIに要求された、記名式切符にあたる
OAuth Tokenの作り方を記述する最初の文書。

補足（持参人切符と記名式切符）: 通常の Bearer Token は
**「持っている人なら誰でも使える切符」**である。
これに対し PoP（Proof of Possession）は、
**鍵の所有を証明できる者だけが使える「記名式切符」**にする、という考え方である。
盗まれても鍵がなければ使えないため、
トークン漏洩そのものが致命傷にならなくなる。
詳しくは「トークン」を参照。

目的

意図しない Client からのリソースに対するリクエストを拒否する。

仕組

クライアント認証により、

  • 誰が（どの Authorization Server が）
  • 誰に（どの Client に対して）

発行した Access Token なのかを確認できる。

詳細

OAuth2.0 mTLS

（最初の派生）

OAuth2.0 mTLSの前身（RFC 8705）に対応するように書かれたので、
コチラが最初の派生と言える。TLS 依存でインフラ構築が必要。

Token Binding

（廃止の傾向）

OAuth2.0 mTLSと同じ TLS 依存だが、
コチラはブラウザが対応しインフラ構築不要の予定だったがブラウザ対応が頓挫し廃止

OAuth2.0 DPoP

TLS に依存せず、アプリケーション・レイヤで処理可能にした仕様。
フロントエンドから使用可能なプラットフォーム上の
公開鍵・暗号化アルゴリズムを使用する。

補足（3 つの派生の整理）: 本ページが挙げる 3 つは、
**「鍵をどの層で持つか」**で分かれている。

仕様 鍵の層 現況
mTLS TLS（クライアント証明書） RFC 8705。FAPI で採用され現役
Token Binding TLS（ブラウザが自動生成） ブラウザ実装が頓挫し事実上廃止
DPoP アプリケーション（JS の鍵） RFC 9449。SPA 向けの主流

mTLS は証明書の配布・更新というインフラ運用が要る代わりに堅い。
DPoP はブラウザ内で鍵を作れるため導入が容易だが、
XSS で鍵ごと悪用される余地が残る。

補足（PoP アーキテクチャ自体は RFC にならなかった）: 参考にある
draft-ietf-oauth-pop-architecture はアーキテクチャ文書として
RFC 化されないまま終了し、実装可能な仕様として結実したのが
上表の mTLS と DPoP である。
本ページが「最初の文書」と位置づけているのは、この経緯による。

参考

IETF

その他

本 Wiki 内

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

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

⚠️ **GitHub.com Fallback** ⚠️