DPoP (RFC 9449) explained: How sender-constrained OAuth tokens make token theft a non-event
Blog post from WorkOS
Demonstrating Proof-of-Possession (DPoP), standardized in September 2023 as RFC 9449, addresses the security vulnerabilities of OAuth 2.0 bearer tokens by binding access and refresh tokens to a client's public/private key pair, requiring a fresh proof JWT for each token and resource request. This method ensures that a stolen token is useless without the corresponding private key, enhancing security against token theft in scenarios such as compromised browser extensions or vulnerable SPAs. DPoP, unlike Mutual TLS which operates at the transport layer, functions at the application layer and is more accessible for clients using Web Crypto or JWT libraries, despite having more complex moving parts in the request path. It is increasingly being adopted in frameworks like Bluesky's atproto and the Financial-grade API Security Profile 2.0 for open banking, which prefer sender-constrained tokens over traditional methods due to their enhanced security features. The implementation details of DPoP include using asymmetric key pairs, managing nonces to prevent replay attacks, and ensuring that private keys remain non-extractable to maintain the security of the token exchange process.