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, proof of possession
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
- GlossaryFederation Assurance Level (FAL)
NIST 800-63C levels describing how strongly a federated login protects the assertion an identity provider (IdP) sends to a relying party (RP). FAL1: the IdP sig
- 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
- PodcastAuth0
The late Vittorio Bertocci's interviews with the authors of OAuth, OpenID Connect, FIDO, and SAML. Ended in 2022, and still the best audio archive on identity s
- 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