DPoP binds an access token to a key held by the client, so a stolen token cannot be replayed by anyone else. The client proves possession of the key on each request with a signed JWT, turning a bearer token into a sender-constrained one without requiring mutual TLS.
DPoP (Demonstrating Proof of Possession)
DPoP (Demonstrating Proof of Possession) (RFC 9449) — DPoP binds an access token to a key held by the client, so a stolen token cannot be replayed by anyone else. The client proves possession of the key on each request with a signed JWT, turning a bearer token into a sender-constrained one without requiring mutual TLS.
- Application-layer proof of possession - Works where mTLS is impractical — browsers, mobile, and most public clients.
- A stolen token stops being enough - The attacker needs the private key as well.
- Recommended by the Security BCP - Alongside mTLS, as the way to move off pure bearer tokens.
- Lighter than mTLS - No certificate infrastructure required.
The modal API authentication story measured across 14,195 published contracts is a plain bearer token — http: bearer appears 4,173 times. DPoP is the low-friction path off that, and it matters most exactly where agents hold long-lived credentials against remote capability endpoints. See The OAuth 2.0 Standard.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The OAuth 2.0 Standard
The low-friction path off plain bearer tokens, which appear 4,173 times across 14,195 published contracts.
