DPoP sender-constrained tokens change the OAuth theft model

At a glance

What this is: DPoP shifts OAuth from bearer-token replay risk to sender-constrained token validation by binding tokens to a client-held key and request-specific proof.

Why it matters: IAM teams need to treat token custody, proof verification, and key storage as part of access governance for public clients, including SPAs, mobile apps, NHI workloads, and AI agents.

By the numbers:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read WorkOS's explanation of DPoP sender-constrained OAuth tokens

Context

OAuth bearer tokens have always been easy to steal because possession equals authority. DPoP changes that assumption by requiring the client to prove possession of a private key at request time, which matters whenever access tokens move through browsers, mobile apps, proxies, or AI agent toolchains.

For IAM and NHI programmes, the key question is no longer only whether a token can be issued or rotated. It is whether the runtime client can safely hold the key, generate fresh proofs, and survive replay attempts without turning token theft into immediate access.

That matters even more as public OAuth clients expand into SPAs and AI agent integrations. The article’s core point is that sender-constraining is becoming a baseline expectation for public clients, not a niche hardening option.

Key questions

Q: How should security teams govern sender-constrained OAuth tokens for public clients?

A: They should treat sender constraining as a mandatory design control for any client that can leak bearer tokens, especially browsers, mobile apps, and AI agents. The practical test is whether the private key can stay bound to the client runtime, whether proofs are validated on every request, and whether replay attempts are rejected before access is granted.

Q: When does DPoP add more value than bearer-token rotation alone?

A: DPoP adds more value when token theft is plausible through logs, extensions, proxies, or script execution, because rotation still assumes the attacker can use the token until it expires. Sender-constrained tokens reduce the usefulness of the stolen token itself, which changes the control objective from limiting lifespan to denying reuse.

Q: What breaks if browser private keys are stored badly for DPoP?

A: If the key is extractable or stored as plain text, an attacker who gains client-side access can exfiltrate the proofing key and turn DPoP into ordinary bearer-token risk again. The control depends on non-extractable storage and on limiting the time window during which active script can mint valid proofs.

Q: Who should own DPoP and sender-constrained token governance?

A: Ownership should sit jointly with identity security, application platform teams, and the teams managing public clients. The reason is that DPoP spans token issuance, proof validation, browser or mobile key storage, and client lifecycle decisions, so no single control domain can govern it alone.

Technical breakdown

How DPoP binds OAuth tokens to a client-held key

DPoP, or Demonstrating Proof-of-Possession, adds a confirmation claim to OAuth tokens so the resource server can verify that the caller owns the private key associated with the public JWK in the proof header. The client signs a short-lived proof JWT for each token and resource request, and the server checks the request method, target URI, issue time, and token hash. This turns token use into a two-part validation: possession of the token and possession of the bound key. Without both, a stolen token is inert. The mechanism is application-layer sender constraining, not transport-layer certificate binding.

Practical implication: identity teams must treat proof validation and key custody as part of the access path, not as an optional API gateway feature.

DPoP versus mTLS for sender-constrained access

mTLS and DPoP solve the same problem from different layers. mTLS binds the token to a client certificate presented during the TLS handshake, which works well for controlled server-to-server environments but depends on certificate lifecycle and TLS termination under your control. DPoP uses asymmetric signatures at the application layer, so it is better suited to browsers, mobile apps, and other public clients that cannot reliably present client certificates. The tradeoff is operational: DPoP removes PKI overhead but adds JWT proof processing, replay tracking, and nonce handling on the server side.

Practical implication: choose mTLS where PKI is already mature and DPoP where the client cannot safely participate in certificate-based transport binding.

Why browser key storage determines whether DPoP actually helps

The private key is the security boundary in DPoP. In browsers, non-extractable Web Crypto keys stored in IndexedDB are the correct pattern because they can sign proofs without being exported as raw material. If the key is extractable or stored in localStorage, an attacker who gains script execution can steal or reuse it, which defeats the control. Even with non-extractable keys, active XSS can still mint proofs while the page is live, so proof windows and token lifetimes still matter. DPoP reduces replay value, but it does not erase client-side compromise.

Practical implication: store browser keys as non-extractable CryptoKeys in IndexedDB and keep token lifetimes short enough to limit active abuse.

Threat narrative

Attacker objective: The attacker wants to replay stolen OAuth access or refresh tokens as if they were the legitimate client and bypass sender-bound authentication.

1. Entry occurs when a bearer token leaks through a browser-based public client, log pipeline, proxy, or extension and an attacker captures the string without the matching private key.
2. Credential access fails to translate into usable authority because the token is bound to the client-held key and each request requires a fresh signed proof JWT with matching htm, htu, and ath claims.
3. Impact is contained because replayed tokens and proofs are rejected unless the attacker can also produce valid proof signatures and satisfy replay and nonce checks.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sender-constrained OAuth is becoming the new baseline for public clients: Bearer tokens fail the moment a client environment can leak strings, which is exactly why browser extensions, logs, and proxies keep appearing in post-mortems. DPoP does not eliminate exposure, but it makes stolen tokens materially less useful because authority is no longer transferable by possession alone. That shifts OAuth governance from token secrecy to proof-of-possession assurance. Practitioner conclusion: public-client access models now need sender-constraining as a design assumption, not an exception.

DPoP exposes an identity governance blind spot in browser and agent runtimes: token binding is only as strong as the runtime that holds the private key and the request path that validates the proof. For AI agents and other public clients, that means the access model is no longer just about scopes and expiries. It is about whether the client can generate, retain, and use its key without creating a new exfiltration path. Practitioner conclusion: treat client key custody as a first-class control surface in NHI and agent governance.

Proof-of-possession shifts the control question from theft detection to replay invalidation: traditional OAuth controls assume the attacker will try to reuse a stolen token before it expires. DPoP changes the field by making the stolen artifact insufficient unless the attacker can also satisfy the proof checks and nonce constraints. This is a named governance concept worth tracking: token possession without authority. Practitioner conclusion: the security model now depends on binding, not just on rotation or short lifetimes.

Access review and rotation assumptions are weaker when the proof layer is dynamic: sender-constrained tokens can expire safely, but they do not solve the programme problem of deciding which public clients are allowed to hold a signing key at all. That is where OAuth governance meets NHI lifecycle controls, because the client key becomes the durable identity object and the access token becomes the ephemeral artefact. Practitioner conclusion: lifecycle governance must extend to browser and agent keys, not just secrets vaults.

DPoP is a category signal for IAM architecture, not just an OAuth feature: once public clients include AI agents, sender-constrained access becomes part of wider identity design across human, NHI, and autonomous programmes. The market implication is clear: access control is moving closer to runtime proof and away from static bearer assumptions. Practitioner conclusion: teams that still design around transferable tokens will keep inheriting replay risk into every new client type.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to the 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, which shows why possession-based access controls keep failing when lifecycle governance is incomplete.
• Track the wider access-governance pattern in the Ultimate Guide to NHIs and compare it with sender-constrained token design choices.

What this signals

Token possession without authority: DPoP matters because it separates theft from use, which is the right design response when public clients can leak bearer strings through browsers, logs, or integrations. For IAM and NHI programmes, that means the control objective shifts from keeping tokens secret to ensuring the runtime can prove possession at the moment of access. The practical signal is that access architecture is moving toward proof-bound identity rather than transferable credentials.

A strong implementation programme will now ask which client classes can safely hold a private key, which ones need certificate-based binding, and which ones should not be trusted with reusable tokens at all. That is where identity policy becomes runtime policy, and where access governance starts to overlap with application security engineering. The teams that align these decisions early will have fewer replay-driven incidents to explain later.

The governance issue is not limited to humans logging into apps. As AI agents become public OAuth clients, sender constraining becomes a baseline requirement for machine access patterns too, because the same token theft problem exists once agents call tools on behalf of users or workflows. Programmes that do not classify these clients separately will keep treating a runtime proof problem as if it were only a credential storage problem.

For practitioners

• Map every public OAuth client to a sender-constraining decision Classify SPAs, mobile apps, and agent-facing clients separately from confidential server-to-server apps, then decide where DPoP or mTLS is required before token issuance is allowed.
• Store browser private keys as non-extractable Web Crypto objects Persist CryptoKey pairs in IndexedDB, not localStorage, and verify that the signing key cannot be exported even if JavaScript execution is compromised.
• Validate replay, nonce, and audience checks at the resource layer Require htm, htu, ath, jti, and nonce validation on every protected endpoint so a stolen token cannot be replayed across requests or services.
• Treat AI agents as public OAuth clients by default If an agent can request tokens for tools or APIs, bind those tokens to proofs and review whether its key custody model matches the blast radius of the access it receives.

Key takeaways

• DPoP changes OAuth from bearer-token possession to proof-bound access, which directly reduces the value of stolen tokens.
• The largest implementation risk sits in client key custody, because a badly stored private key can collapse sender-constraining back into bearer semantics.
• IAM, NHI, and agent governance now need explicit decisions on which public clients may hold signing keys and which must use stronger binding.

Key terms

• Sender-constrained token: An access token that is bound to a specific client-held secret or key, so possession of the token alone is not enough to use it. In practice, the resource server checks a proof tied to that client before granting access, which reduces replay value if the token leaks.
• 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.
• Nonce challenge: A server-issued one-time value that the client must include in its next proof to prevent immediate replay. It adds a freshness check to request validation and is especially relevant when public clients operate in environments where proofs may be intercepted before use.

Deepen your knowledge

DPoP sender-constrained token governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing public-client access for browsers, mobile apps, or AI agents, it is worth exploring.

This post draws on content published by WorkOS: DPoP explained and how sender-constrained OAuth tokens change token theft risk. Read the original.