OAuth 2.0 DPoP

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is an extension to the OAuth 2.0 protocol, standardized as RFC 9449, that cryptographically binds access tokens to the client they were issued to. An ordinary bearer token works for whoever holds it; a DPoP-bound token works only for an application that can also prove possession of the private key used to obtain it, which makes a copied token worthless on its own.

The main goal is to prevent the use of leaked or stolen access (and refresh) tokens, such as those exposed through cross-site scripting (XSS) or other vulnerabilities anywhere in the implementation and network stack.

How does OAuth DPoP work

The proof of possession is done via a JSON Web Token (JWT) that is included as a header in an HTTP request. The DPoP proof JWT is used by a client to demonstrate possession of a private key corresponding to a specific public key. The DPoP proof is essentially a signature over certain data in the HTTP request, including a timestamp, a unique identifier, an optional server-provided nonce, and a hash of the associated access token if present.

The OAuth flow with DPoP involves a client sending an authorization grant to the authorization server to obtain an access token (and possibly a refresh token). The client attaches a DPoP proof to the request in an HTTP header. The authorization server binds the access token to the public key claimed by the client in the DPoP proof, ensuring the access token cannot be used without proving possession of the corresponding private key. If a refresh token is issued, it is also bound to the public key of the DPoP proof.

To use the access token, the client must prove possession of the private key by including a DPoP proof in the request header. The resource server verifies the public key match and checks the access token hash in the DPoP proof against the presented access token.

The DPoP mechanism is not a client authentication method but is compatible with various client authentication methods. It doesn't directly ensure message integrity but relies on the Transport Layer Security (TLS) layer for that purpose.

ClientAuthorization serverResource server token request, with a proof signed by the client's keyaccess token, bound to that key's thumbprintAPI request, access token, and a fresh proof proof key vs. thumbprintresponse, or 401 if the key is absent
DPoP governs two hops: the proof at issuance, which tells the authorization server which key to bind the token to, and the proof at use, which is what a thief of the token alone cannot produce.

Key Advantages

DPoP has several advantages over plain bearer tokens.

  • A token intercepted or leaked without its private key cannot be replayed by an attacker.
  • The resource server can verify on every request that the caller holds the private key associated with the access token, rather than trusting whoever presents it.
  • It works at the application layer, so it suits client types where mutual TLS is impractical, including browser-based applications, mobile apps, and Internet of Things (IoT) devices.

Key Challenges

DPoP also has challenges that need to be addressed.

  • It requires clients to generate and protect a private key, which can be difficult in some environments; a key an attacker can extract, for example through the same XSS that exposes the token, defeats the binding.
  • Support is not yet universal across authorization servers, resource servers, and client libraries, so every party in a flow has to be checked before relying on it.
  • It does not replace other security measures such as TLS and public key infrastructure (PKI), and should be used in conjunction with them.

DPoP is related to other Identity and Access Management (IAM) standards and technologies such as Mutual TLS (mTLS) and JSON Web Tokens (JWTs). mTLS is another mechanism for binding client certificates to access tokens, while JWTs are a popular format for representing claims securely between two parties. DPoP can be used in conjunction with these technologies to provide a more secure and fine-grained access control mechanism.