DPoP (Demonstrating Proof of Possession)

DPoP (Demonstrating Proof of Possession at the Application Layer, RFC 9449, 2023) est un standard OAuth 2.0 ajoutant proof de possession aux access tokens — empêche un attaquant ayant volé un token (via XSS, log leak, network intercept) de l'utiliser depuis un autre device. Token "bound" cryptographically au client.

Problème résolu : OAuth access tokens classiques (bearer tokens) sont copy-paste — quiconque les a peut les utiliser. DPoP solve ça en exigeant que chaque API request inclue un DPoP proof (signed JWT) prouvant possession de la private key associated au token.

Fonctionnement :
(1) Client génère key pair (typically EC256 or RS256) au démarrage app, persists in browser secure storage (IndexedDB, WebCrypto subtle key non-exportable).
(2) Client request token from IdP avec DPoP header : `DPoP: <JWT signed with private key, including public key in jwk>`.
(3) IdP issues access token bound to public key (cnf claim ou jkt — JWK Thumbprint).
(4) Client makes API request avec `Authorization: DPoP <access_token>` + `DPoP: <new JWT proof per request>` (each proof unique : jti, htm = HTTP method, htu = URL, iat).
(5) Resource server verify : (a) JWT signature with client's public key ; (b) public key matches access_token cnf claim ; (c) htm/htu match current request ; (d) iat recent (anti-replay).

Force vs bearer tokens : (1) **Token theft useless** without private key — XSS exfiltrating localStorage useless ; (2) **No need mTLS** — works over standard HTTPS ; (3) **Per-request proof** — fresh signature each time prevent replay ; (4) **Decentralized** — no shared secret between client/server beyond public key.

Adoption :
(1) **Auth0** — DPoP support 2024.
(2) **Microsoft Entra ID** — DPoP support certaines contexts.
(3) **FAPI 2.0** (Financial-grade API) — DPoP recommended pour sender-constrained tokens.
(4) **OpenBanking** — security standard recommandé.
(5) **OAuth 2.1** — DPoP referenced as recommended pour sender-constrained tokens.

Alternative : **mTLS** sender-constrained tokens (RFC 8705) — bind token au TLS client cert. Same goal, different implementation. mTLS requires PKI infrastructure, DPoP works browser-side easier.

Limitations : (1) **Browser key storage** — must use WebCrypto non-exportable keys, lost if user clears site data ; (2) **Implementation complexity** ; (3) **Limited library support** still maturing.

Use cases : (1) High-value APIs (banking, healthcare) ; (2) Long-lived tokens needing sender-constraint ; (3) SPAs concerned about XSS theft ; (4) Mobile apps where token storage challenging. Compétences SC-300, AZ-500.