TL;DR: DPoP, standardised in RFC 9449, binds OAuth tokens to a client-held key and requires a fresh proof JWT on each request, making stolen bearer tokens unusable without the matching private key, according to WorkOS. That changes token theft from a simple replay problem into a key custody and proof-validation problem that IAM, NHI, and agentic OAuth designs now have to account for.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: DPoP sender-constrained OAuth tokens change the token theft model by binding tokens to a client-held asymmetric key and requiring per-request proof.
Why it matters: It matters because IAM and NHI teams must treat OAuth theft as a key-custody and proof-validation issue, not just a bearer-token replay problem.
Context
Bearer OAuth tokens are replayable by design, which is why leakage through logs, browser memory, extensions, or intermediaries has remained such an effective theft path. DPoP changes that trust model by binding the token to a client-held key and requiring a fresh proof for each token and resource request.
For identity programmes, this is not only an OAuth hardening detail. It affects how public clients, browser-based apps, mobile apps, service integrations, and AI agents handle token custody, request signing, and replay resistance across the access lifecycle.
Key questions
Q: How should teams secure public OAuth clients that cannot hold bearer tokens safely?
A: Use sender-constraining for any public client that can leak tokens through browsers, mobile storage, logs, or intermediaries. DPoP is the common application-layer option when client certificates are not practical. The key decision is whether the client can prove possession of a private key on every request, not whether the token is merely hidden.
Q: Why do stolen OAuth tokens stop being immediately useful under DPoP?
A: Because the access token is bound to a specific client key, a stolen string does not authorise access unless the attacker can also sign the required proof JWT. The replay problem shifts from possession of the token to possession of the matching private key and valid request context.
Q: What are the signs that a DPoP deployment is failing in practice?
A: Common signs include proof replays that are accepted, mismatched request method or URI checks, weak nonce handling, or private keys stored in extractable form. If proofs are not tied to the actual request and token, DPoP is functioning more like logging than access control.
Q: When should organisations choose DPoP instead of mutual TLS?
A: Choose DPoP when the client is a browser, mobile app, or other public client that cannot realistically manage certificates. Choose mutual TLS when you control the transport and certificate lifecycle, especially in server-to-server environments. The tradeoff is client fit versus transport strength, not just implementation preference.
Technical breakdown
How DPoP binds tokens to a client-held key
DPoP, or Demonstrating Proof-of-Possession, moves OAuth away from pure bearer semantics. The authorization server issues tokens with a cnf.jkt confirmation claim that points to the client public key thumbprint, while the client signs a short-lived proof JWT with the matching private key on each request. The resource server checks the proof signature, the HTTP method and URI, the access-token hash, and the token binding before allowing access. A stolen token alone is no longer sufficient. The security property now depends on both token custody and key custody, plus accurate proof validation on the server side.
Practical implication: review any OAuth flow that still assumes possession of the token is enough to grant access.
Why proof JWT replay controls matter
The proof JWT is intentionally ephemeral. It contains a unique jti, an issue time, and request-specific claims such as htm, htu, and often ath, which ties the proof to the presented access token. Servers reject reused or stale proofs, and many deployments add server-issued nonces to reduce the window for interception and replay in hostile environments. That means the control boundary is no longer just token validation. It includes freshness, request binding, and replay detection at both the authorization server and the resource server.
Practical implication: validate proof freshness and replay handling as part of every OAuth security review.
Sender-constraining versus transport-layer binding
DPoP and mutual TLS solve the same broad problem, but at different layers. Mutual TLS binds tokens to a client certificate and is strong in controlled server-to-server environments, but it is awkward for browsers and many mobile or public-client use cases. DPoP works at the application layer, so it fits public clients that cannot manage certificates, including browser apps and AI-agent-facing OAuth clients. The tradeoff is added request-path complexity, key storage discipline, and strict server verification requirements. In practice, sender-constraining shifts the question from whether the token leaked to whether the requester can prove possession of the bound key.
Practical implication: choose the sender-constraining mechanism that matches the client type and operational model.
Threat narrative
Attacker objective: The attacker wants to reuse a stolen OAuth token to impersonate the legitimate client and access protected resources.
- Entry occurs when a bearer token leaks through a browser, extension, log line, proxy, or device store, giving an attacker a reusable string under classic OAuth assumptions.
- Escalation is blocked when the attacker cannot produce the matching proof JWT signed by the client-held private key, because the token is bound to that key through the cnf claim.
- Impact is reduced because replayed tokens and proofs fail validation, preventing straightforward API access even after token disclosure.
Breaches seen in the wild
- GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.
- JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bearer-token replay is no longer the right mental model for high-risk public OAuth clients. DPoP replaces pure possession-based access with a proof-of-possession requirement, which changes the governance problem from token leakage alone to token-plus-key custody. That matters most where clients cannot be fully trusted, such as browsers, mobile apps, and AI agents acting as public clients. Practitioners should treat sender-constraining as part of the access model, not as an afterthought.
Proof freshness is now a core access control property. A DPoP deployment only works when servers enforce htm, htu, iat, jti, and optional nonce checks consistently. That turns replay detection into a first-class identity control, not just a transport concern. The practical implication is that access controls now depend on both token issuance and per-request proof validation, which needs deliberate governance across authorization and resource servers.
Key custody becomes the new trust boundary for OAuth-based machine access. When the client is a browser app or AI agent, the private key is the asset that substitutes for bearer-token possession. That means storage location, non-extractability, rotation, and revocation are part of the identity design, not implementation details. The governance question shifts to whether the organisation can actually control the client-held key over the full token lifecycle.
Sender-constraining exposes a gap in conventional lifecycle thinking for public clients. Access review models assume a stable credential or entitlement can be observed and recertified over time, but DPoP makes the relevant proof transient and request-bound. The implication is that identity governance has to move closer to issuance and runtime verification when the client itself is part of the trust decision.
DPoP should be read as a structural response to bearer-token fragility, not as a niche OAuth enhancement. The article’s strongest signal is that public clients are becoming a category where replay resistance must be designed in, especially as OAuth patterns extend into AI-agent integrations. Practitioners should evaluate whether their current OAuth controls still assume bearer semantics anywhere in the delegation chain.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
What this signals
Sender-constrained access should now be treated as a design requirement for public clients. Browser-based and agent-based OAuth flows cannot rely on bearer semantics if token leakage is part of the threat model. For identity teams, the question is no longer whether token replay can happen, but whether the client can prove possession at request time.
Key custody is the new control surface. Once a token is bound to a client-held key, the security programme has to care about where that key lives, how it is persisted, and how it is rotated or invalidated. That makes OAuth governance closer to non-human identity control than many teams currently assume.
For practitioners
- Harden public OAuth clients with sender-constraining Require DPoP or an equivalent sender-constraining mechanism for browser apps, mobile clients, and other public clients that cannot safely hold bearer tokens. Make the choice explicit in architecture review so token replay is not your default trust model.
- Store client keys as non-extractable material Use browser or platform key stores that keep the private key non-extractable and bound to the device or runtime. Avoid string-based storage for any private key material because it defeats proof-of-possession.
- Enforce proof validation on every resource request Check the DPoP signature, the request method, the request URI, the access-token hash, the key thumbprint, and replay indicators before granting access. Make these checks consistent across token and resource endpoints.
- Define nonce and replay handling clearly Set server-side rules for nonce issuance, nonce rotation, proof age, and jti uniqueness so replay windows are narrow and deterministic. Separate authorization-server and resource-server handling rather than treating them as one pool.
- Review OAuth paths used by AI agents Identify any agent or automation that relies on public OAuth clients and decide whether bearer semantics are still acceptable. If the client can initiate actions autonomously, proof-bound access becomes part of the runtime trust model.
Key takeaways
- DPoP changes OAuth from bearer-token possession to proof-bound access, which makes replayed tokens ineffective without the matching private key.
- The practical security boundary shifts to key custody, proof freshness, and server-side validation of each request.
- Teams running public OAuth clients should decide whether bearer semantics are still acceptable anywhere in their access model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | DPoP hardens OAuth authentication for non-human and public clients. |
| NHI-02 — Secret Leakage | Stolen bearer tokens from logs, browsers, or proxies are the core threat DPoP addresses. | |
| Recommendation — Use DPoP to bind OAuth requests to a client-held key and reduce replayable authentication risk. Limit token leakage paths and treat exposed OAuth tokens as unusable only when sender-constrained. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token binding and private-key custody map to authenticator lifecycle controls. |
| Recommendation — Apply authenticator management controls to bound OAuth credentials and rotate compromised keys. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | DPoP changes how request authorization is validated for public clients. |
| Recommendation — Enforce request-level authorization checks that verify token binding and proof-of-possession. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Token theft and reuse are credential-access patterns that sender-constraining is meant to blunt. |
| Recommendation — Map token theft scenarios to Credential Access and hunt for replayable bearer tokens in exposed paths. | ||
Key terms
- Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
- Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
- Proof JWT: A short-lived signed JWT that a client presents to prove it owns the private key bound to a token. The server validates its signature, request target, method, time, and token hash. For autonomous and NHI clients, this becomes part of the identity runtime, not just an authentication detail.
- Non-extractable key: A cryptographic key stored in a way that allows signing operations but prevents export of the raw private material. In browser-based DPoP, this is the practical control that keeps a stolen script from simply copying the proofing key and replaying access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org