Bearer tokens can be constrained in such a way that only the client/entity that received it can actually be used. When such tokens are presented as an authorization grant,  the receiving service/API can evaluate the legitimacy of the token by asking for  proof of possession. Access is granted only if the presenter of the token also produces the proof. Since only the client/entity to whom the token was originally issued can present the proof, requests with stolen or leaded tokens are rejected. This approach renders the stolen tokens unusable. 

There are two methods to constrain bearer tokens and demand proof of possession:

1. -

   mTLS based proof of possession : [OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://datatracker.ietf.org/doc/html/rfc8705)OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.

2. -

   Asymmetric cryptography and JWT based proof of possession : [OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer. ](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop)OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer. 

In this blog post, we’ll briefly discuss the two methods. 

Tokens constrained with certificates are called [certificate-bound access tokens](https://konghq.com/blog/engineering/mtls-sender-constrained-tokens)certificate-bound access tokens. With this approach, the access tokens are bound to the client certificate used in establishing a mutual TLS connection to the authorization server. Issued tokens contain a thumbprint of the certificate. When a client makes a request to a protected resource, the client is expected to present the same mTLS certificate as proof along with the token obtained from the authorization server. The receiving party can grant access only after validating that the thumbprint of the certificate in the token matches the presented proof (mTLS certificate). Requests with missing certificates or mismatched certificates and tokens are rejected. Stolen or leaked tokens cannot be used as an additional proof (in the form of certificate) needs to be presented along with the token.

DPoP is a OAuth security extension to constrain bearer tokens to clients. It is designed to work at the application layer. Unlike mTLS, it does not rely on PKI infrastructure. This approach leverages asymmetric cryptography and JSON Web Tokens. With DPoP, bearer tokens are constrained to the client using the client’s private key.

Although DPoP is relatively new compared to the mTLS-based approach, which is widely adopted, DPoP is better suited for a public client such as a single-page application running in a browser. Since it does not rely on PKI, it is less cumbersome to deploy and much easier to implement.

### Comparison of the two methods

With both methods, access tokens are sender-constrained, requiring clients to present proof of possession of tokens. The choice between the two methods depends on factors such as existing infrastructure, security requirements, and tooling ecosystem. 

In Kong Gateway Enterprise 3.5, we introduced constraining tokens using mTLS. Kong authorizes the request only after validating that the thumbprint of the client certificate in the token matches the client certificate used to establish the mTLS connection. With Kong Gateway Enterprise 3.7, we offer support for the second method DPoP.

RFC [9449](https://datatracker.ietf.org/doc/rfc9449/)9449 defines another mechanism to sender-constrain the access tokens. This approach leverages asymmetric keys and JWTS. The authorization server constrains the tokens by binding the tokens to the client’s public key. Clients have to prove the possession of a private key when using the tokens. Recipients of such tokens are then able to verify the binding of the token to the key pair that the client has demonstrated that it holds, thereby providing some assurance that the client presenting the token also possesses the private key. In other words, the legitimate presenter of the token is constrained to be the sender that holds and proves possession of the private part of the key pair.

Starting with the 3.7 release, Kong offers support for application-level PoP mechanisms.

### ** Let’s examine the flow in depth: **

1. - Step 1: The client generates a key pair consisting of public and private keys.
2. - Step 2: The client then prepares a JWT. Includes the public key in the JWT header. The JWT payload consists of claims such as **htm and htu**. Note htu is the requested resource (token endpoint url) and htm is the method. The client signs the JWT with the private key.

3. - Step 3: The client then makes a request to the authorization server’s token endpoint. It includes the client credentials, the grant type, and the JWT as a DPoP header.

4. - Step 4: The authorization server authenticates the client, generates an access token and binds the public key to the token. The server responds back with the access token
5. - Step 5: Clients must generate a ‘proof JWT’ for each request. (Note,  validity of the proof JWT is configurable. Its possible to retry a request within the time period without having to generate new proof JWT). The client then prepares another JWT. This is the DPoP proof JWT. It includes the public key in the header. The hash of access token is included as **ath **claim in the payload along with **htm **and **htu** claims. Note the htu is the requested resource and htm is the method. The client then signs the JWT with the private key. 

6. - Step 6: The client then makes a request for the protected resource by including the access token in the **Authorization: DPoP** <> header and the proof JWT as **DPoP header**.

7. - Step 7: Kong extracts the DPoP proof JWT and the access token from the request. The signature is verified using the public key included in the Dpop proof. This proves that the client has the private key corresponding to the public key. Next, it checks the public key in the proof JWT matches the public key bound to the access token. This proves that the client is the valid owner of the token.

Requests with just a token or requests that have mismatched proofs or missing proofs altogether are rejected.

The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens. This is achieved by binding a token to a public key upon issuance and requiring the client to prove the possession of the corresponding private key when using the token. This mechanism constrains the token to be used only by the legitimate owner of the token and provides added assurance that the sender of the token is legitimately authorized to use it.

Sender-constrained tokens are suitable implementations for environments with high security requirements such as financial-grade APIs or [Open Banking](https://konghq.com/solutions/open-banking)Open Banking. The DPoP mechanism offers a new way to implement sender-constrained tokens and is designed to work at the application layer.

With support for DPoP in Kong Gateway Enterprise 3.7, Kong enforces proof-of-possession checks for both methods of sender-constrained tokens.