andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Learn what DPoP is and how it works under the hood to enhance your application security and  mitigate the effects of access token theft.

As a developer, you're likely familiar with OAuth 2.0 and the use of access tokens to secure APIs. As you may know, the usage model for traditional OAuth 2.0 access tokens is defined in [RFC 6750](https://tools.ietf.org/html/rfc6750), where a **bearer token** is defined as a simple string that grants access to the "bearer" of the token.

For years, this has been the standard way to use access tokens. It's simple and effective, but it has a fundamental weakness: if a token is stolen, an attacker can use it to impersonate the legitimate user or application. Tokens can be leaked in numerous ways: through a compromised client device, insecure log files, a [person-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack), or a malicious browser extension. Once leaked, a bearer token is a golden ticket for an attacker.

## Beyond Bearer Tokens

To address this critical vulnerability, the concept of **sender-constraining** tokens was developed. The goal is to ensure that a token can only be used by the party it was originally issued to. If we compare an access token to a keycard to access your hotel room, it's like using a keycard that only works when accompanied by your unique fingerprint. Several mechanisms have been proposed to achieve this, but one has emerged as a flexible, powerful, and modern standard: **Demonstrating Proof-of-Possession (DPoP)**, standardized in [RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html).

DPoP is a security mechanism that cryptographically binds access and refresh tokens to the specific application instance that requested them. It does this by requiring the client to prove it possesses a secret private key every time it uses the token. This proof is lightweight, works at the application layer, and is perfectly suited for today's diverse application landscape, from server-side web apps to mobile apps and Single-Page Applications (SPAs).

This article will take you on a deep dive into DPoP. We'll explore the security threats it mitigates, dissect its inner workings with code examples, compare it to other sender-constraining methods, and walk through a practical guide on how to implement it in your applications using Auth0.

## The Benefits of DPoP

Adopting DPoP isn't just about adding another layer of security; it's about fundamentally hardening your application against a whole class of common attack vectors. The benefits are tangible and address real-world threats.

### Enhanced security against token theft

This is the primary reason DPoP exists and is also recommended by the [Best Current Practices for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700#name-sender-constrained-access-t). Let's consider a few concrete scenarios where bearer tokens are vulnerable and how DPoP protects them:

* **Cross-Site Scripting (XSS):** An attacker injects malicious code into a web page, which then steals an access token from the browser's local storage or memory. With a bearer token, the attacker can now make API calls on behalf of the user. With DPoP, the stolen token is useless because the attacker doesn't have the client's private key required to generate the DPoP proof.  
* **Compromised Log Files or Databases:** A developer might accidentally log an `Authorization` header containing a bearer token. If these logs are breached, the token is exposed. Similarly, if a database storing tokens is compromised, they are all at risk. A DPoP-bound token, even if exposed, cannot be used without the corresponding private key, which should never be logged or stored alongside the token.  
* **Malicious Browser Extensions:** A seemingly harmless browser extension could have permissions to inspect network traffic or memory, allowing it to exfiltrate tokens. Again, using DPoP, the stolen token is inert without the proof-of-possession key.

By binding the token to the client's key, DPoP prevents an access token from being used by an unauthorized party.

### Flexibility for modern applications

Other attempts at sender-constraining, like [Mutual TLS (mTLS)](https://auth0.com/docs/secure/sender-constraining/mtls-sender-constraining), operate at the transport layer (the [TLS handshake](https://auth0.com/blog/the-tls-handshake-explained/)). This is very secure but also rigid. It requires managing X.509 certificates on the client, which is straightforward for server-to-server (confidential) clients but a nightmare for public clients like SPAs running in a browser or mobile applications. Browsers provide very limited APIs for managing cryptographic keys and client certificates, making mTLS impractical for these use cases.

DPoP, by contrast, operates at the **application layer**. The "proof" is just a JWT sent in an HTTP header. This means:

* **Any client can implement it:** JavaScript in a browser can use the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API), a mobile app can use native cryptographic libraries, and a backend server can use standard JWT libraries.  
* **It works through intermediaries:** Modern infrastructure often includes proxies, gateways, and load balancers that might terminate the original TLS connection from the client. In such a setup, the mTLS binding is lost. DPoP, being part of the application-level data (i.e., HTTP headers), passes through these intermediaries untouched, maintaining end-to-end security.

### No complex Public Key Infrastructure (PKI) required

mTLS relies on a [Public Key Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) (PKI). This means clients need to obtain a certificate from a trusted Certificate Authority (CA), which vouches for their identity. This involves generating certificate signing requests (CSRs), managing certificate lifecycles (issuance, renewal, revocation), and configuring trust stores. For large-scale applications with thousands or millions of clients, this operational overhead is significant and costly.

DPoP completely sidesteps this complexity. Each client application instance simply generates its own public/private key pair on the fly. There is no CA, no certificate chain to validate, and no complex infrastructure to maintain. The resource server trusts the public key for the lifetime of the token because the client proved possession of the private key at the time of the token request.

### Protection for high-value refresh tokens

Refresh tokens are often more valuable targets than access tokens because they are long-lived and can be used to mint new access tokens. DPoP can also be used to sender-constrain refresh tokens. When a client uses a DPoP-bound refresh token to get a new access token, it must also provide a DPoP proof. This ensures that even if a refresh token is stolen from a client's storage, it cannot be used by an attacker to maintain persistent access to the user's account.

### FAPI 2.0 ready

Sender constraining is one of the requirements of [FAPI 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html), the security framework built on top of OAuth 2.0 and designed for high-security applications to protect sensitive data and financial transactions. DPoP is one of the mechanisms allowed in FAPI 2.0 to implement sender constraining.

> Auth0 provides you with support for FAPI 2.0 through [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity). Read [this blog post to learn more about Auth0’s support for FAPI 2.0](https://auth0.com/blog/fapi-2-0-the-future-of-api-security-for-high-stakes-customer-interactions/).

## How DPoP Works

The magic of DPoP lies in a special, short-lived JSON Web Token called the **DPoP proof JWT**. This ephemeral JWT serves as irrefutable evidence of the client's ownership of a specific private key. When a client intends to access a protected resource, it first generates this DPoP proof JWT, signing it with its private key. This signed proof is then transmitted alongside the access token to the resource server.

To understand the behavior of DPoP, we need to look at its key parts. Our exploration will start with a detailed examination of the DPoP proof JWT's structure, becoming familiar with the various claims that contribute to its cryptographic integrity. Following this, we will analyze the DPoP flow, considering two stages: 

* the initial **access token request**, where the client obtains its access token while simultaneously establishing its cryptographic identity,   
* the subsequent **token usage**, where the client leverages both the access token and the DPoP proof JWT to securely interact with the resource server.

## The Anatomy of a DPoP Proof JWT

A DPoP proof is a standard JWT, but with specific claims and header parameters tailored for this purpose.

The header identifies the token as a DPoP proof and contains the public key. Here is an example of a decoded header:

```json
{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": {
    "kty": "EC",
    "x": "l8tFrhx-34tV3hRICRDY9zC_qjKipZWEvVunexs60A8",
    "y": "Hlnr5TL2ncfXj_i9W2nL1pW2QYj45s4T2l5MIa4WVKw",
    "crv": "P-256"
  }
}
```

Here is the meaning of the claims:

* `"typ": "dpop+jwt"`: This type explicitly declares the JWT's purpose. Servers can immediately reject any JWT in the `DPoP` header that doesn't have this type.  
* `"alg"`: This specifies the signing algorithm. It **must** be an asymmetric algorithm (e.g., ES256). Symmetric algorithms are forbidden because they would require the server to know the client's secret, defeating the purpose.  
* `"jwk"`: This is the [JSON Web Key](https://datatracker.ietf.org/doc/html/rfc7517), which is the public key corresponding to the private key used to sign the proof. This is how the client shares its public key with the server for validation.

The payload contains claims that bind the proof to a specific HTTP request, preventing it from being stolen and replayed in a different context. Here is an example of DPoP proof payload:

```json
{
  "jti": "5a2c4187-2418-4568-a5b7-f4a4d61858b1",
  "htm": "POST",
  "htu": "https://your-tenant.auth0.com/oauth/token",
  "iat": 1678886400
}
```

Here is the description of the claims in the payload:

* `"jti"` (JWT ID): A unique identifier for this specific JWT. This is crucial for **replay prevention**. A server should keep track of jti values it has recently seen and reject any duplicates.  
* `"htm"` (HTTP Method): The HTTP method (GET, POST, PUT, etc.) of the request to which this proof is bound. This prevents a proof created for a GET request from being used on a POST request.  
* `"htu"` (HTTP Target URI): The full URL of the endpoint being called, excluding query parameters and/or fragments. This can be the token endpoint or the API endpoint, as you will see shortly. This ensures a proof intended for `https://api.example.com/orders` cannot be used for `https://api.example.com/users/delete`.  
* `"iat"` (Issued At): A timestamp indicating when the JWT was created. Servers should reject proofs that are too old (e.g., older than a few seconds) to further mitigate replay attacks.

> Optionally, at the request of the [authorization server](https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-server-provid) or the [resource server](https://datatracker.ietf.org/doc/html/rfc9449#name-resource-server-provided-no), the payload of the DPoP proof JWT can include a nonce claim. Its value is generated by the server and sent to the client via the DPoP-Nonce HTTP header. The nonce aims to mitigate replay attacks in public clients, i.e., SPA and native apps.

The final part of the JWT is the signature, created by signing the base64-encoded header and payload with the private key that corresponds to the public key stored in the `jwk` claim of the header. **This is the cryptographic "proof" of possession**.

## Requesting a DPoP-Bound Access Token

Now that we know the structure of a DPoP proof JWT, let’s see how to use it for protecting our requests and access tokens. As we mentioned earlier, we will analyze the DPoP flow in two stages. The first stage is about requesting an access token from the authorization server. Following the diagram below, let’s analyze the steps of the flow.

![A sequence diagram illustrating the OAuth 2.0 security flow for requesting a DPoP-bound access token, showing the key generation and DPoP proof submission.](https://images.ctfassets.net/23aumh6u8s0i/7ERtf626Ra1xdORkMXxJsB/2a86d45120dc10a673253c6b0d149f9c/access-token-request-with-dpop.png)

1. In the first step, the client application **generates a new public/private key pair**.  
2. The client **constructs the DPoP proof JWT** for the token endpoint. The DPoP proof JWT is signed with the client’s private key and contains the corresponding public key.  
3. The client makes a POST request to the `/oauth/token` endpoint. It includes the standard parameters (`grant_type`, `code`, etc.) and adds the newly created `DPoP` proof in a DPoP HTTP header. The following snippet shows an example of access token request with the DPoP header:

```HTTP
POST /token HTTP/1.1 
Host: your-tenant.auth0.com 
Content-Type: application/x-www-form-urlencoded 
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...  

grant_type=authorization_code 
&code=3LgurgEWbtafaqTn2VxkASV 
&redirect_uri=https%3A%2F%2Fapp.example.com
```

4. The authorization server validates the DPoP proof JWT by verifying the signature using the public key stored in the `jwk` claim of the header. It also verifies that the target URL and HTTP method of the current request match the `htu` and `htm` claims in the payload.  
5. If the request is valid, it generates an access token. The authorization server also generates a SHA256 [thumbprint of the client's public key](https://datatracker.ietf.org/doc/html/rfc9449#name-jwk-thumbprint-confirmation-). This information will be used to confirm the binding of the client's public key with the issued token. In case the issued access token is an opaque string, the authorization server includes this information in the response returned by the [token introspection endpoint](https://datatracker.ietf.org/doc/html/rfc7662). If the issued token is a JWT, the authorization server adds a `cnf` (confirmation) claim to the access token's payload, as shown in the following snippet:

```json
{
  "iss": "https://your-tenant.auth0.com/",
  "sub": "user|12345",
  "aud": "https://api.example.com/orders",
  "exp": 1678890000,
  "iat": 1678886400,
  "scope": "read:orders",
  "cnf": {
    "jkt": "N_i4l4295g9kE2xStSIyYAnr727xO0I5n82x4NaIphE" // SHA-256 thumbprint of the JWK
  }
}
```

The access token is ready to be used by the client to securely access the user’s resources.

## Using the DPoP-Bound Access Token

Let’s see how the access token is used to access a protected resource by following the numbered steps in this diagram:

![A sequence diagram showing how a DPoP-bound access token is used to prevent access token theft during an API call, highlighting the DPoP proof validation at the resource server.](https://images.ctfassets.net/23aumh6u8s0i/5GgT1vzY4xdEHmvs9DjdiM/d3551f170703e51a6b8d81083c6306df/api-call-with-dpop-bound-token.png)

1. As the first step, the client application **creates a new DPoP proof JWT** using the same key pair previously generated. This is a critical point. The client cannot reuse the old proof. For every API request, it must create a **new** DPoP proof with a fresh `jti` and `iat`, and with `htm` and `htu` matching the API endpoint it's about to call.  
2. The client application **sends the request to the resource server** (the API). It includes two important headers:  
   * `Authorization: DPoP \<access\_token\>`. Instead of the classic `Bearer` scheme, the `DPoP` scheme is used. This signals the server that it must perform DPoP validation.  
   * `DPoP`: The newly generated DPoP proof for this specific request.

The following is an example of an API request with a DPoP-protected access token:

```HTTP
GET /protectedresource HTTP/1.1 
Host: api.example.com 
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K0pXVCIsImNuZiI6eyJqa3QiOiJybW56aTJvSWNYW...
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...
```

3. When the resource server receives the request, it performs a **comprehensive validation**. To the usual [token validation checks](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens), it adds the following ones:  
   * Checks for the presence of the `cnf` claim. If it's missing, this isn't a DPoP-bound token.  
   * Verifies the DPoP proof's signature using the `jwk` in its header.  
   * Computes the SHA-256 thumbprint of the `jwk` from the DPoP proof and compares it with the `jkt` value inside the access token's `cnf` claim. **They must match.** This is the step that confirms the presenter of the token is the same one it was issued to.  
   * Validates that the `htm` and `htu` in the DPoP proof match the current API request's method and URL.  
   * Checks the `iat` and `jti` to prevent replay attacks.  
4. Only if all these checks pass, the API processes the request and **returns the protected resource**. A stolen token will fail to access a DPoP-protected resource because the attacker cannot produce a valid DPoP proof signed by the correct private key.

> Take a look at [this interactive tutorial, which shows the full DPoP flow](https://dpop.info/) for getting an access token and calling a protected API.

<include src="ebook-ads/Oauth2OidcGuide" />

## Conclusion

The era of relying solely on bearer tokens is drawing to a close, especially for applications handling sensitive data. The risks of token theft are too significant to ignore. DPoP provides a robust, flexible, and developer-friendly solution to the problem of sender-constraining tokens. It effectively mitigates threats from XSS, compromised devices, and log leaks by cryptographically binding tokens to the client that requested them.

By operating at the application layer, DPoP offers broad compatibility across all types of clients&mdash;from back-end services to browser-based SPAs and native mobile apps&mdash;without the heavy infrastructure requirements of transport-layer solutions like mTLS.

With platforms like Auth0 offering built-in support, implementing this advanced security measure is no longer a daunting task. By enabling DPoP, you take a significant and proactive step towards building more secure, resilient applications that protect both your users and your systems.

Protect Your Access Tokens with DPoP (Demonstrating Proof of Possession)

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

Brian Campbell joins the show to discuss sender constraint and associated specifications.



### The Overview

On the first episode of _Identity, Unlocked_, host Vittorio Bertocci, Principal Architect at [Auth0](http://www.auth0.com?utm_source=podcast&utm_medium=blog&utm_campaign=identity-unlocked), is joined by Brian Campbell. Brian joins the show to discuss the sender constraint and associated specifications. 
 
The mechanism described by OAuth2 for using the access token to access resources, as defined in the bearer token usage specification ([RFC6750](https://tools.ietf.org/html/rfc6750)), simply entails attaching a token to the request to the API. The approach is extremely simple to implement, but token leaks can have disastrous consequences: nothing stops an attacker from using a stolen bearer token to access a resource successfully. 

"Sender constraint" indicates a series of techniques that bind tokens to a particular sender, for example, by forcing the token to travel on a specific channel or requiring proof of knowledge of a given key. The goal is to guarantee that only the legitimate sender can successfully use a token to access resources, thus making it impossible for an attacker to access a resource using leaked tokens. 

There are two different specifications in the OAuth 2 family offering viable sender constraint capabilities today: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS, [RFC8705](https://tools.ietf.org/html/rfc8705)) and OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html)). 

MTLS is robust and stable, but not easy to implement in various important scenarios. For a while, the identity community worked on an alternative, a set of specifications under the general token binding moniker (main one: [RFC8471](https://tools.ietf.org/html/rfc8471)); however, support from key industry players disappeared or never materialized, making token binding non-viable.

DPoP quickly emerged as an easy to implement an alternative that could fill that gap, and although it is still in draft state, it is already very popular and making quick progress.

Brian touches on all those specs during the episode, walking us through the trajectory that led us to today's situation and taking the time to dig deeper into the trade-offs, strengths, and attention points of the various approaches. The episode concludes with important practical considerations to keep in mind when planning an implementation strategy for the sender constraint in your solutions today.  

Read on for more in-depth information on this episode and make sure to subscribe and join us for the next episode, where [Aaron Parecki](https://twitter.com/aaronpk) (Senior Security Architect) talks about what's new with OAuth2.1.

### Highlights:

In the following, we highlight key passages of the interview. We added some background information here and there to make it easier to follow the conversation if you aren't already familiar with the topic.

**[4:45]** - What is sender constraint and what problem is it trying to solve?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=9506a0f1&embed=true"></iframe> 

The figure below shows a typical OAuth 2 flow for calling an API- a good example to understand how bearer tokens are meant to work.

![Bearer](https://images.ctfassets.net/23aumh6u8s0i/3IJk6fHvBHJcUj5za8yAmt/78444158ad7ab009e2c2a1bddf66b027/1-bearer)

In the first leg of the diagram, a client requests an access token - this might be the redemption of an authorization code, of a refresh token, anything that leads to an access token being issued to the client as shown in step 2.
In this particular example, we are issuing tokens that are digitally signed by the `authorization` server via its private key (other token encodings are possible).

In step 3, the client calls the API by simply attaching the access token to the request (typically by placing it in the authorization HTTP header).

In step 4, the API validates the incoming access token (in this example, that includes validating the signature with the public key associated with the authorization server), and the call succeeds. 

The following diagram shows what happens when a bearer token is leaked.

![BearerAttack](https://images.ctfassets.net/23aumh6u8s0i/5TsCBLxiteQCHodPQYdMhp/3657fc2c592b822f960b90395be69cc0/2-bearerattack)

In step 1, an attacker steals an access token. For the purpose of highlighting the problem with bearer token leaks, it doesn't matter how the leak occurs (the token might be leaked from a cache, a referral header, an HTTPS tunnel termination, erroneously forwarded to a malicious address etc., etc.) as it doesn't change the consequences of the leak.
Once an attacker has the token, all they need to do to access the API successfully is to attach it to an API call - the API will perform the same validation we had observed in the former diagram when the call was originating the legitimate sender. 
This is the key limitation of bearer tokens: everything hinges on not making them fall into the wrong hands, as when that happens, there's no easy recourse.

**[11:35]** - What are the current standards with sender constraint?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=1e5c3b2a&embed=true"></iframe>

The main specifications extending OAuth 2 with sender constraint capabilities are:

* MTLS ([RFC8705](https://tools.ietf.org/html/rfc8705))
* DPoP ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html))
* Token binding ([RFC8471](https://tools.ietf.org/html/rfc8471))

Token binding is mentioned out of exhaustiveness, but it isn't really a viable option as of today. 
For the other ones, we give more details later on in the interview.

**[11:51]** - Brian explains mutual TLS profile for OAuth 2.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=d98141ee&embed=true"></iframe>

Here's a super quick primer to explain how MTLS works in OAuth 2. This leaves out lots of details, so if you are interested, you should consider taking a look at the spec itself ([RFC8705](https://tools.ietf.org/html/rfc8705)).
Please consider the diagram below.

![MTLS](https://images.ctfassets.net/23aumh6u8s0i/3nVuTSuMHCkIm7XS3pyxDw/5a97276eaa4f3a1a8e7f1c45d1a08274/3-mtls)

The client application has access to an X509 certificate, which it uses to perform client TLS authentication (hence proving possession of the corresponding private key) when requesting a token from the authorization server.
The authorization server issues a token containing (or referencing, if other token encoding methods are used) a claim cnf carrying the thumbprint of the X.509 certificate used to establish the channel. 
Important note: the access token is still meant to be signed by the authorization server, and the API is still meant to validate that signature, but we are omitting it in all diagrams from now on for simplicity. 

In step 2, the client establishes a channel with the API/resource server, again using its X509 certificate to establish client TLS. 

In step 3, the API validates the incoming token as usual, and additionally, it verifies that the certificate thumbprint corresponds to the certificate used to establish the TLS channel. If the two matches, the call is considered valid.  

![MTLSAttack](https://images.ctfassets.net/23aumh6u8s0i/479dKTr0VNwPDUT3i8Fwyl/e57676ac4b63edca06a5409ba42d6e3a/4-mtlsattack)

Consider now the case in which an attacker successfully steals a token. The attacker does not have access to the same certificate as the legitimate client; hence it cannot establish a client TLS channel with the API when attempting to use the stolen token - or it has to use a different certificate.
However, the API will easily spot that the certificate thumbprint carried by the cnf claim in the incoming access token does NOT correspond to the certificate used in client TLS authentication by the attacker; hence the API will deny access.

**[15:32]** - Brian explains DPoP. 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=36aff654&embed=true"></iframe>

To help you follow the discussion, here’s a diagram exemplifying how DPoP works. 

![DPOP](https://images.ctfassets.net/23aumh6u8s0i/xrkq0ZMdUIwjiCeuZ6aXf/f333027993663e18e5f714e7d7d43d7f/5-dpop)

The idea is simple: the client uses some keys when requesting a token, those keys are referenced by the access token issued by the authorization server, and the client demonstrates knowledge of the same keys to the resource server when using that access token to call an API. Let's break that down in the steps shown in the diagram.

The client generates a private-public keys pair. It then creates a JWT, called DPoP proof, including in it a claim `jwk`carrying the public key from the pair, an `htu` claim indicating the intended destination of the call (in this case, something like [`https://server.example.com/token`](https://server.example.com/token)), a claim `htm` the HTTP method to be used in the call, and (not shown in the diagram) a `jti` claim (identifier) and an `iat` claim (issuance instant). It then proceeds to digitally sign the JWT with the private key from the generated pair.

In step 1, the client attaches the DPOP proof in a DPOP HTTP header to a token request to the authorization server.

In step 2, the authorization server uses the public key in the `jwk` claim from the DPoP proof to validate its signature, verifying that the sender does indeed have access to the corresponding private key. That done; it issues a new access token (once again, the token signature is omitted, but it is there, just like in the first diagram in this post) and embeds in it a `cnf` claim containing the public key received from the client.

In step 3, the client calls the API. Using the DPoP, the client creates a new DPoP proof, including the same `jwk` with the generated public key, a `htu` with the URL of desired API endpoint (for example, [`https://resource.example.org/protectedresource`](https://resource.example.org/protectedresource)) and `htm`, `jti`, and `iat` claims of the appropriate value. The client then attaches the DPoP proof and the access token to the request to the API.

In step 4, the client validates the incoming access token as it would do in a normal bearer case. In addition to that, it validates the DPoP signature with the `jwk` it carries, validates that the content of the DPoP proof accurately describes the targeted API and thatthe thumbprint of the key embedded in the `cnf` claim in the incoming access token corresponds to the `jwk` in the DPoP proof. If all that checks out, the API has proof that the caller is indeed entitled to use that token and allows the request to succeed.
The failure case here is very similar to the one shown in the MLTS diagram. An attacker stealing a token would not have access to the private key the legitimate client-generated at request time; hence it would not be able to manufacture the appropriate DPoP proof that would convince the API to accept the stolen access token. Bam. Sender constraint!

**[18:42]** - If DPOP blossoms like some anticipate, is there any reason to continue mutual TLS?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=db16444d&embed=true"></iframe>

**[23:23]** - Brian’s opinion on how DPoP can be rolled out.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=dcdf8d37&embed=true"></iframe>

### Links/Resources:

Learn more about [Brian Campbell](https://www.linkedin.com/in/bcampbell)<br />
Brian Campbell on [Twitter](https://twitter.com/__b_c)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
Vittorio Bertocci on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


"sender_constraint"