Skip to main content
Identity Authority
Category: OAuth & OIDC

Demonstrating Proof of Possession

Also known as: DPoP, Demonstration of Proof of Possession, Demonstrating Proof-of-Possession, OAuth 2.0 Demonstrating Proof of Possession at the Application Layer
Simply put

DPoP is a security mechanism for OAuth 2.0 that ties a token to the specific client that requested it, so a stolen token cannot simply be reused by an attacker. It works by having the client prove, with each request, that it holds a private cryptographic key associated with the token. This makes tokens harder to misuse if they are intercepted or leaked.

Formal definition

DPoP, specified in RFC 9449, is an application-level mechanism for sender-constraining OAuth 2.0 (RFC 6749) access and refresh tokens. The client generates an asymmetric key pair and, on each protected request, sends a signed JWT proof (a DPoP proof) demonstrating possession of the corresponding private key; the token is bound to that key so that presentation of the token alone is insufficient without a matching proof. DPoP is an OAuth 2.0 authorization framework extension focused on token binding at the application layer; per the evidence, it addresses sender-constraining tokens and is distinct from authentication of the end user. Exact proof structure, key confirmation claims, and validation behavior depend on the RFC 9449 profile and the specific authorization server and resource server implementation.

Why it matters

Bearer tokens are the default in most OAuth 2.0 deployments, and their defining weakness is exactly that: whoever bears the token can use it. If an access or refresh token is intercepted in transit, leaked through logs, exfiltrated from a compromised client, or exposed by a mishandled redirect, an attacker can typically replay it against the resource server with no further proof required. DPoP addresses this specific class of risk by sender-constraining the token so that presentation of the token alone is insufficient without a matching cryptographic proof.

DPoP, specified in RFC 9449, matters because it raises the bar for token theft without requiring the heavier infrastructure of some alternative binding approaches. By binding an OAuth 2.0 access or refresh token to a key held by the requesting client, a stolen token becomes far less useful to an attacker who does not also hold the corresponding private key. This is particularly relevant for public clients and browser-based applications, where mutual-TLS-based sender-constraining is often impractical to deploy.

It is important to scope DPoP correctly: it is a token security mechanism concerned with sender-constraining tokens at the application layer, not a means of authenticating the end user. DPoP reduces the impact of token leakage; it does not by itself establish who the user is, which remains the concern of an authentication layer such as OpenID Connect. The exact protection DPoP provides depends on the RFC 9449 profile and on how the authorization server and resource server implement and validate proofs.

Who it's relevant to

Security architects
Architects evaluating token security models should treat DPoP as one option for sender-constraining OAuth 2.0 tokens, particularly for public clients and browser-based applications where mutual-TLS binding is difficult to deploy. The decision to adopt DPoP, and the strength of protection it yields, depends on the RFC 9449 profile and on consistent support across both the authorization server and resource servers.
IAM and OAuth engineers
Engineers implementing OAuth 2.0 flows need to handle asymmetric key pair generation on the client, construction and signing of the DPoP proof JWT on each request, and validation of both token and proof on the resource server. Exact proof structure, key confirmation claims, and validation behavior vary by implementation, so engineers should follow RFC 9449 and their platform's guidance closely.
Application and API developers
Developers building clients that hold access and refresh tokens benefit from DPoP because it reduces the impact of a leaked or intercepted token, since the token cannot typically be replayed without the matching private key. Developers should confirm that their authorization server and the APIs they consume support DPoP before relying on it.
Compliance and audit leads
Those assessing token-handling controls can note DPoP as a mechanism that binds tokens to a specific client to mitigate replay of stolen bearer tokens. It should be documented as a token security control, not as an end-user authentication mechanism, since sender-constraining and authentication address different concerns.

Inside DPoP

DPoP proof JWT
A JWT created by the client and sent in the DPoP HTTP header on token and resource requests. It is signed by the client's private key and carries claims that bind the request to that key, such as the HTTP method (htm), the HTTP URI (htu), a unique identifier (jti), and a timestamp (iat).
Client-held key pair
An asymmetric key pair generated and held by the client. The public key is embedded in the DPoP proof header (typically as a JWK), while the private key never leaves the client and is used to sign each proof. The specific algorithms and key handling depend on the client implementation and configuration.
JWK thumbprint confirmation (cnf/jkt)
A confirmation claim that binds the issued access token to the client's public key. The authorization server typically records a JWK thumbprint in the token (for example a jkt value in a cnf claim) so the token is usable only by a holder that can prove possession of the matching private key.
Sender-constrained (DPoP-bound) access token
An access token that is cryptographically tied to the client's key rather than being a pure bearer token. Using it requires presenting a valid DPoP proof for the same key, which addresses token theft and replay in a way ordinary bearer tokens do not.
Resource server validation logic
The verification a protected resource performs at request time: checking the DPoP proof signature against the embedded public key, confirming the htm/htu match the actual request, validating freshness via iat/jti, and confirming the proof's key matches the token's bound key thumbprint. This is a runtime enforcement concern, separate from token issuance.

Common questions

Answers to the questions practitioners most commonly ask about DPoP.

Does DPoP authenticate the user to the resource server?
No. DPoP is a mechanism for binding a token to a client's cryptographic key pair so that the token can only be used by the party holding the corresponding private key; it addresses token binding and proof of possession, not user authentication. Establishing who the user is remains the job of an authentication layer such as OpenID Connect, and determining what the presenter may do remains a matter of authorization. DPoP demonstrates that the presenter possesses the private key associated with the token, which is a distinct concern from verifying the identity of the end user.
Is a DPoP proof the same as encrypting the access token?
No. A DPoP proof is a signed JWT that demonstrates possession of a private key; signing provides integrity and proof of possession, not confidentiality. The access token itself is typically bound to the client's public key (via a key thumbprint confirmation claim) but is not encrypted by DPoP. Because a signed proof or token can still be read by anyone who intercepts it, transport-level protection such as TLS remains necessary. Treat signing and encryption as separate properties: DPoP relies on the former and does not, on its own, provide the latter.
How does a client construct a DPoP proof for a request?
In typical implementations, the client generates or reuses a key pair and creates a DPoP proof JWT for each request. The proof commonly includes the public key in its header and, in most profiles, carries claims identifying the HTTP method and target URI of the request along with a unique identifier and a timestamp. The client signs the proof with its private key and sends it in a dedicated DPoP HTTP header alongside the access token. Exact claim names and required fields depend on the DPoP specification profile and library in use, so verify against the version you are implementing.
How is a DPoP-bound access token validated at the resource server?
Validation generally involves two linked checks. First, the resource server validates the access token as it normally would for its type, verifying signature and claims for a self-contained token, or performing introspection for an opaque token. Second, it verifies the accompanying DPoP proof: confirming the proof's signature using the public key it carries, and confirming that the public key's thumbprint matches the key-binding confirmation claim associated with the token. Depending on configuration, it may also check the proof's request method and URI, timestamp freshness, and replay protection identifiers. Both the token check and the proof check must succeed.
How can replay of a captured DPoP proof be mitigated?
DPoP proofs typically include a unique identifier and a timestamp so that a resource or authorization server can reject reused or stale proofs. In many deployments the server maintains a short-lived cache of recently seen proof identifiers to detect replays within an acceptance window, and rejects proofs whose timestamps fall outside that window. Because proofs are commonly bound to a specific HTTP method and URI, a captured proof is also less useful against a different endpoint. The precise replay defenses available depend on the profile and server implementation, and none remove the need for TLS.
Where does DPoP fit relative to bearer tokens and mutual-TLS binding?
DPoP is one approach to sender-constrained tokens, intended for scenarios where binding a token to a client key is desired without relying on mutual TLS. A plain bearer token can be used by any party that obtains it, whereas a DPoP-bound token additionally requires proof of the associated private key. Mutual-TLS client-certificate binding is an alternative sender-constraining mechanism that binds tokens to a TLS client certificate. The appropriate choice depends on deployment context, client capabilities, and infrastructure; none is universally superior, and support varies by vendor and profile.

Common misconceptions

DPoP authenticates the user, making it an authentication mechanism.
DPoP operates within OAuth 2.0, which is a delegated authorization framework, not an authentication protocol. DPoP proves that the client presenting a token possesses the corresponding private key; it constrains how a token may be used and does not by itself establish who the end user is. User authentication is handled by separate mechanisms such as OpenID Connect.
A DPoP proof or DPoP-bound token is encrypted, so its contents are confidential.
DPoP proofs are signed JWTs, and signing provides integrity and proof of possession, not confidentiality. Unless separately encrypted, the JWT claims are readable by anyone who intercepts them. Transport-level protection remains necessary.
DPoP is functionally the same as mutual TLS (mTLS) certificate-bound tokens.
Both aim to produce sender-constrained tokens, but DPoP achieves this at the application layer using a client-held key and per-request signed proofs, whereas mTLS binding relies on the TLS certificate. They are distinct mechanisms with different deployment requirements, and the appropriate choice depends on the environment and configuration.

Best practices

Treat DPoP-bound tokens as sender-constrained rather than bearer tokens, and ensure resource servers reject a DPoP-bound access token presented without a valid, matching DPoP proof.
Validate every element of the DPoP proof at the resource server: signature against the embedded public key, htm and htu matching the actual request, and freshness via iat, with jti tracking to detect replay where feasible.
Confirm that the key in the DPoP proof matches the key thumbprint bound to the access token (for example the cnf/jkt value) so a proof cannot be reused with a different token.
Keep the client's private key protected in the client environment and, where the platform supports it, in non-exportable or hardware-backed storage appropriate to the deployment.
Enforce a bounded acceptance window for proof timestamps and account for clock skew per your configuration to limit the reuse window without breaking legitimate clients.
Verify that your authorization server, clients, and resource servers all support compatible DPoP profiles before relying on it, and clearly document that DPoP addresses token binding and possession, not user authentication.
Promotional banner for the Pentest Readiness checklist download