DPoP

2 articles

Cybersecurity 20 Sep 2026 7 min read

DPoP Binds OAuth Access Tokens to a Client Key

DPoP Binds OAuth Access Tokens to a Client Key A bearer access token is usable by any party that obtains the token and can present it to the resource server. TLS protects the token while it crosses a correctly authenticated connection, but it does not change that bearer property after the token reaches an endpoint, log, process, browser context, or other storage location. Demonstrating Proof of Possession (DPoP), specified by RFC 9449, adds a key-bound layer at the application protocol. The client creates an asymmetric key pair and signs a DPoP proof JWT. An authorization server can bind an issued access token to the public key represented by that proof. The resource server then requires both the token and a valid proof created with the corresponding private key.

Cybersecurity OAuth

Cybersecurity 19 Sep 2026 6 min read

DPoP Binds OAuth Tokens to Client Keys, Not to Client Identity

A bearer access token normally authorizes whichever party can present its value to a resource server. Copying the token can therefore move its authority away from the client that originally received it. OAuth 2.0 Demonstrating Proof of Possession, or DPoP, changes that property by binding a token to a public key and requiring a signed proof from the corresponding private key during presentation. That binding narrows one important failure mode, but it does not turn the key into a universal client identity. DPoP is an application-layer sender-constraining mechanism. Its guarantees depend on the token binding, proof validation, replay policy, TLS, and the security of the client execution context.

Cybersecurity OAuth