Tokenを鍵へ結び付ける
Authorization ServerはClient公開鍵のthumbprintをアクセストークンへ記録し、Resource Serverが同じ鍵の証明を要求できるようにします。
Overview
この仕様は、
何を解決するのか。
アクセストークン漏えい後の再利用まで防ぎたいAPI設計者や、Bearer TokenとSender-Constrained Tokenの違いを学びたい人向けです。DPoPは、OAuthアクセストークンをClientが持つ鍵ペアへ結び付ける仕組みです。通常のBearer Tokenは持っている人なら誰でも利用できますが、DPoP Tokenは対応する秘密鍵でリクエストごとの証明を作れるClientだけが利用できます。
ClientはToken EndpointとResource ServerへのリクエストごとにDPoP Proof JWTを作ります。ProofにはHTTP Method、送信先URI、発行時刻、一意なjtiなどが含まれ、Resource Serverは署名と内容、アクセストークンとの鍵Bindingを検証します。
Purpose and responsibilities
仕様が定める、大切なこと。
漏えいTokenの再利用を防ぐ
攻撃者がアクセストークンだけを取得しても、対応する秘密鍵がなければ有効なAPIリクエストを作れません。
リクエスト単位で証明する
htmとhtuでProofをHTTPリクエストへ結び付け、別Endpointや別Methodへの転用を防ぎます。
Key concepts
01DPoP Proof JWT02Public-key Binding03dpop+jwt04jti / htm / htu05Token Replay Protection
Security considerations
安全に使うための確認事項。
仕様を実装するときは、正常系の通信だけでなく、値のすり替え、再利用、漏えいが起きた場合も考えます。
- 01
秘密鍵はClient外へ出さず、可能ならOSのKey Storeやハードウェア保護領域へ保存します。
- 02
Resource Serverは署名、typ、jti、iat、htm、htu、athと公開鍵Bindingをまとめて検証します。
- 03
Proofのjtiと短い有効時間を利用してReplayを検出し、必要に応じてServer Nonceを要求します。
- 04
DPoPはTLSを置き換えません。TokenとProofは常にHTTPSで送信します。
Position and relationship
ほかの仕様との関係
DPoPはOAuth 2.0のBearer TokenをSender-Constrained Tokenとして強化します。相互TLSも同じ目的を持ちますが、DPoPはアプリケーション層の鍵証明を使うため、Public Clientやプロキシを含む構成で採用しやすい特徴があります。
Other specifications
OAuth 2.0 (RFC 6749)The OAuth 2.0 Authorization Framework→OAuth 2.0 Device Authorization (RFC 8628)OAuth 2.0 Device Authorization Grant→OAuth 2.1OAuth 2.1 Authorization Framework→OpenID Connect Core 1.0OpenID Connect Core 1.0→FIDO2 WebAuthn Level 3Web Authentication: Public Key Credentials→FIDO2 CTAP 2.2Client to Authenticator Protocol→FIDO UAF 1.1Universal Authentication Framework→FIDO U2F 1.2Universal Second Factor→OpenID Connect CIBA Core 1.0Client-Initiated Backchannel Authentication→OAuth 2.0 PKCE (RFC 7636)Proof Key for Code Exchange by OAuth Public Clients→JSON Web Token (RFC 7519)JSON Web Token (JWT)→SAML 2.0Security Assertion Markup Language 2.0→SCIM 2.0 (RFC 7644)System for Cross-domain Identity Management: Protocol→