DPoP
Demonstrating Proof of Possession (RFC 9449). Binds an access token to a specific key held by the client, so a stolen bearer token cannot be replayed. Important for high-assurance APIs that cannot rely on mTLS.
DPoP exists because bearer tokens are the last big replay hole in OAuth: steal one and you are the client. It binds the token to a key the client proves possession of on every request, so a token lifted from a browser or a log is useless elsewhere. mTLS-bound tokens do the same job with better performance where you control the transport; DPoP is the option for public clients and browser apps that cannot present a client certificate.
See also: access token, token theft, mTLS, OAuth 2.1
Related on Start with Identity
- GlossaryFAPI
Financial-grade API. A hardened OAuth and OIDC security profile from the OpenID Foundation for high-risk APIs such as open banking, mandating stronger client au
- GlossaryX.509
The standard format for public-key certificates used in TLS and PKI. An X.509 certificate binds a public key to a subject and is signed by a certificate authori
- GlossaryAgentic Identity
Identity for autonomous AI agents that act on a user's behalf, call APIs, and chain tools. Requires scoped, delegated, auditable, and revocable credentials rath
- CVEDrupal Simple OAuth/OIDC auth bypass via an alternate path
Drupal Simple OAuth / OIDC 6.0.0 through 6.0.6 allowed authentication to be skipped on an alternate path. Patched in 6.0.7.
- CVEDuende OAuth token management mixes tokens across requests
A race in Duende's .NET OAuth token-management package could attach client A's token to client B's request. Session mix-up, not a crypto break, but it is still
- CVEOAuth 2.0 private_key_jwt audience ambiguity
A specification-level flaw in the OAuth 2.0 JWT profile: private_key_jwt audience is ambiguous, so a token minted for one authorization server can be accepted b