OAuth DPoP
OAuth DPoP, short for Demonstrating Proof of Possession, is the RFC 9449 method for making OAuth token use depend on a client-held signing key instead of bare possession of an access-token string.
Definition
OAuth DPoP is an application-level proof-of-possession mechanism for OAuth 2.0 access and refresh tokens. RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP), was published by the IETF in September 2023 with D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, and D. Waite as authors.
The problem DPoP addresses is bearer-token portability. RFC 6750 defines bearer-token usage: a party that possesses the token can use it unless another control blocks the request. DPoP changes the acceptance rule. The caller must present the token and a fresh signed proof showing control of the private key associated with the token's public-key binding.
For AI agents, if an access token leaks through a tool trace, browser log, support bundle, or connector boundary, DPoP can make the copied string less reusable. It does not decide whether the authorized agent should have made the request.
How It Works
A DPoP client generates or holds an asymmetric key pair. When it calls an authorization server or protected resource, it sends a DPoP HTTP header whose value is a signed JWT called a DPoP proof. RFC 9449 requires the proof header to identify the token as dpop+jwt and to carry the public JWK corresponding to the signing key.
The proof payload binds the proof to the request. Required claims include jti, a unique proof identifier; htm, the HTTP method; htu, the HTTP target URI; and iat, the issued-at time. For protected-resource calls, RFC 9449 requires the ath claim, a hash of the access token. Servers may also use a server-provided nonce claim to reduce replay windows.
The authorization server binds a DPoP access token to the client's public key using cnf.jkt, the JWK thumbprint confirmation member. A resource server then checks the token, proof signature, method and URI claims, access-token hash, freshness, replay identifier, and key binding. RFC 9449 also defines metadata named dpop_signing_alg_values_supported for proof-signing algorithm discovery.
Agent Context
Agent systems create unusual token paths: a human may approve a task, a model may select a tool, a runtime may call a connector, and a remote API may receive the request. Without sender constraint, any place that records the token string can become a replay point.
DPoP is useful when an agent runtime should use a token but a copied token should not be enough. A well-designed connector keeps the private key outside model-visible context and avoids storing proof JWTs or key material in ordinary traces.
The control should be described accurately. DPoP can reduce replay of copied tokens. It cannot prove that a user intended a particular side effect, that a model selected the right tool, or that a prompt-injected workflow is harmless. If the legitimate key holder signs a bad request, the DPoP checks may all pass.
Governance and Safety
The governance question is key custody. If the private key appears in prompts, logs, crash reports, browser storage, or shared connector state, DPoP's replay benefit is weakened. If the key is isolated by user session, tenant, resource, and tool boundary, the compromise surface is smaller.
Resource servers need replay defenses. RFC 9449 discusses proof identifiers, issued-at times, nonces, access-token hashes, and server checks because proof possession alone is not enough. Teams should decide how long to remember jti values, when to require nonce challenges, and how to log failures without storing secrets.
DPoP should also be combined with ordinary authorization discipline: narrow scopes, audience and resource restriction, short token lifetimes, revocation paths, approval records, and monitoring for unusual tool use. It is a token replay control, not a general agent-safety system.
Defense Pattern
- Use DPoP for replay-sensitive connectors. Prioritize APIs where a copied token would let an attacker read, write, delete, spend, deploy, or message.
- Keep keys out of model context. The model may request a tool call, but it should not see or emit the private signing key.
- Bind narrowly. Separate signing keys by task, tenant, user session, resource, or connector where that reduces shared authority.
- Verify all proof fields. Check method, URI, token hash, signature, key binding, timestamp, nonce if required, and replay identifier.
- Log the class, not the secret. Record DPoP use, thumbprint, validation result, resource, scope, actor, and action without persisting key material or reusable proof JWTs.
- Threat-model the signer. Test prompt injection and compromised connector behavior, because DPoP cannot stop an authorized signer from making an unsafe request.
Source Discipline
Claims about DPoP should name the standard and the validation path. A precise incident note should say whether the token was bearer or DPoP-bound, whether the private key leaked, whether the resource server checked ath, htm, htu, jti, iat, and nonce, and whether the final request was replayed or legitimately signed.
DPoP should not be collapsed into mutual TLS, token exchange, PKCE, refresh-token rotation, or API-key signing. Those controls can complement each other, but they answer different questions.
Spiralist Reading
Spiralism reads DPoP as a small refusal of ambient authority. A token string alone should not become a wandering permission. The system asks for a second fact: does this caller hold the bound key for this request?
That is not moral proof. It is custody proof. In agent systems, custody proof matters because delegation becomes hard to reconstruct once tokens, tools, logs, and model outputs blur together. DPoP helps keep one boundary legible.
Open Questions
- Which agent connectors should require DPoP-bound tokens rather than bearer tokens?
- Should proof keys be per session, per connector, per resource, per user, or per high-risk task?
- When should nonce challenges be mandatory for agent-originated requests?
- How should approval records distinguish a valid DPoP proof from a valid human authorization?
Related Pages
- Sender-Constrained Tokens
- OAuth Token Exchange
- OAuth Security Best Current Practice
- OAuth Resource Indicators
- OAuth Protected Resource Metadata
- OAuth Token Introspection
- OAuth Token Revocation
- AI Agent Identity
- Confused Deputy Problem
- Capability-Based Security
- Model Context Protocol
- Tool Use and Function Calling
- AI Agent Sandboxing
- AI Audit Trails
- Prompt Injection
- AI Governance
Sources
- D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, and D. Waite, IETF, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), September 2023.
- IETF Datatracker, RFC 9449 HTML text, reviewed for proof JWT syntax,
cnf.jkt,ath, nonce behavior, metadata, and security considerations. - M. Jones, D. Hardt, and D. Recordon, IETF, RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage, October 2012.