OAuth 2.0 DPoP

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is an extension to the OAuth 2.0 protocol that provides a mechanism for cryptographically binding access tokens to a particular client when they are issued. This technique is one of many attempts at improving the security of Bearer Tokens by requiring the application using the token to prove possession of the same private key that was used to obtain the token.

The main goal is to prevent the unauthorized or illegitimate use of leaked or stolen access (and refresh) tokens, such as which can occur with cross-site scripting (XSS) and also other vulnerabilities in the whole implementation/network stack.

How does OAuth DPoP work

The Demonstration of Proof of Possession (DPoP) is done via a JSON Web Token (JWT) that is included as a header in an HTTP request. The DPoP proof JWT is utilized 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 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 key advantages over other token-based authentication mechanisms.

  • Firstly, it provides a higher level of security than traditional Bearer Tokens, which can be intercepted and used by attackers.
  • Secondly, DPoP allows for more fine-grained access control, as it enables the server to verify that the client is in possession of the private key associated with the access token.
  • Finally, DPoP is compatible with a wide range of client types, including web applications, mobile apps, and IoT devices.

Key Challenges

However, DPoP also has some key challenges that need to be addressed.

  • Firstly, it requires clients to have access to a private key, which can be difficult to manage in some environments.
  • Secondly, DPoP is still a relatively new technology, and there is a lack of standardization around how it should be implemented.
  • Finally, DPoP is not a silver bullet for security, and it should be used in conjunction with other security measures such as TLS and PKI.

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.