DPoP (Demonstrating Proof of Possession).

An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key. It belongs to the Identity & Access category of cybersecurity.

An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key.

DPoP (Demonstrating Proof of Possession at the Application Layer), specified in RFC 9449, is an OAuth 2.0 mechanism that converts bearer tokens into sender-constrained tokens without requiring mutual TLS. The client generates an ephemeral asymmetric key pair, includes the public key's JWK thumbprint as `jkt` in the access token (issued by the IdP), and on every API call sends a short-lived JWT proof signed with its private key in the `DPoP` HTTP header. The proof commits to the HTTP method, the request URI, and a fresh nonce or jti, so an attacker who steals the access token but lacks the private key cannot forge a valid proof. Resource servers verify the proof matches both the token's bound key and the current request. DPoP is one of two practical answers to OAuth bearer-token theft (the other being mTLS-bound tokens) and is now widely supported by Okta, Auth0, Entra ID, Keycloak, and several open-source libraries. Combined with PKCE and short refresh-token lifetimes, DPoP dramatically reduces the value of a stolen token to an attacker.

Defences for DPoP (Demonstrating Proof of Possession) typically combine technical controls and operational practices, as detailed in the full definition above.

Common alternative names include: RFC 9449, Demonstrating Proof of Possession.