OAuth 2.1 and DPoP: where token security is heading
OAuth 2.1 and DPoP: where token security is heading
OAuth 2.1 (still draft, 16th revision) consolidates best practice: no implicit flow, PKCE required, exact redirect matching. DPoP (RFC 9449) sender-constrains tokens — the practical answer to token exfiltration.
OAuth 2.1 + DPoP
As of: 2026-02
OAuth 2.1 (draft-16)
Not an RFC yet, but it is the de-facto practice bar: PKCE mandatory for all clients, implicit flow dead, redirect URIs exact-match, bearer tokens discouraged where PoP is available, refresh token rotation expected. Build to 2.1 even while it's a draft — nothing in it will regress.
DPoP (RFC 9449, 2023)
Sender-constrained tokens: the client holds a private key and proof-jwt's each request; a stolen access token replayed elsewhere fails the proof check.
- Flow: client generates ephemeral keypair;
DPoPheader carries a JWT (method+uri+iat+jti+ath); AS binds the token to the public key (cnf.jkt). - Resource servers validate the proof — libraries exist in all majors (node-oidc-provider, Spring Authorization Server, django-oidc).
- mTLS (RFC 8705) is the heavier alternative; DPoP wins for browser/mobile clients.
For agent platforms
API keys are bearer tokens — one DPoP-style upgrade path for high-value agent credentials is binding the key to the agent's runtime keypair. Expect the ecosystem to move this direction.