DPoP

DPoP introduces a proof-of-possession layer that binds an access token to an asymmetric key pair held exclusively by the client. The client generates a DPoP proof JWT signed with its private key, embedding the token's hash (ath claim) and a unique nonce. This ensures that even if a bearer token is exfiltrated, it cannot be replayed by an attacker who does not possess the corresponding private key.

• Uses asymmetric cryptography (RSA or EC keys)
• Embeds the access token hash in the ath claim
• Prevents token replay attacks across different TLS connections

DPoP employs a server-issued nonce to prevent proof replay within the token's validity window. When a resource server receives a DPoP proof, it validates the nonce and may issue a fresh one via the DPoP-Nonce HTTP header. The client must use the most recent nonce in subsequent requests, creating a monotonically advancing sequence that makes captured proofs immediately stale.

• Server controls nonce lifecycle via DPoP-Nonce header
• Prevents proof replay even within token TTL
• Enables stateless validation with short-lived nonces

Each DPoP proof is scoped to a specific HTTP request by embedding the target URI (htu claim) and HTTP method (htm claim) directly in the signed JWT. This prevents an intercepted proof from being redirected to a different endpoint or upgraded to a more privileged method. The binding creates a cryptographic coupling between the proof, the token, and the exact operation being authorized.

• htu claim: exact target URI (scheme, host, path, query)
• htm claim: HTTP method (GET, POST, PUT, DELETE)
• Prevents cross-endpoint replay and method escalation

The DPoP proof is a signed JWT with a well-defined structure. The header includes the public key (jwk) and signing algorithm (typ: dpop+jwt). The payload contains mandatory claims: jti (unique ID), htm (HTTP method), htu (target URI), iat (issued-at timestamp), and optionally ath (access token hash). The signature proves possession of the private key without revealing it.

• Header: { "typ": "dpop+jwt", "alg": "ES256", "jwk": {...} }
• Payload: jti, htm, htu, iat, ath (optional)
• Self-contained proof requiring no server-side key storage

While both DPoP and Mutual TLS (mTLS) provide proof-of-possession, they operate at different layers. mTLS binds tokens to the transport layer, requiring certificate management infrastructure. DPoP operates at the application layer, making it suitable for multi-hop architectures, mobile apps, and scenarios where TLS termination occurs at a load balancer. DPoP proofs survive TLS termination and can traverse API gateways.

• DPoP: application layer, survives TLS termination
• mTLS: transport layer, requires end-to-end TLS
• DPoP is SPA and mobile-friendly without client certificates

In multi-agent systems, DPoP provides a critical security layer for inter-agent communication. When Agent A delegates a task to Agent B, DPoP ensures that only Agent B—the legitimate key holder—can wield the delegated token. This prevents agent impersonation attacks and unauthorized token forwarding in agent mesh networks. Combined with SPIFFE workload identities, DPoP creates end-to-end cryptographic accountability across agent chains.

• Prevents token forwarding between unauthorized agents
• Binds delegated authority to a specific agent instance
• Integrates with SPIFFE for workload identity attestation

A mechanism to cryptographically bind application-layer bearer tokens to a TLS connection, preventing token export and replay attacks. While DPoP binds a token to a specific public key, Token Binding binds it to the underlying transport layer. This creates a layered defense: if an attacker steals a DPoP-bound token, they still cannot use it without the private key; if they bypass the application layer, the token remains bound to the original TLS channel, rendering it useless in a different session.

A mutual authentication protocol where both client and server present X.509 certificates to establish a bidirectional trusted, encrypted channel. Unlike DPoP, which operates at the application layer, mTLS secures the transport layer itself. In agentic systems, mTLS is often used alongside DPoP to provide defense-in-depth: mTLS authenticates the workload identity at the network level, while DPoP proves possession of a key bound to the specific OAuth access token.

A hardware-based security paradigm that protects data in use by performing computation within a Trusted Execution Environment (TEE). In the context of DPoP, confidential computing ensures that the private key used for proof-of-possession never leaves the secure enclave. Even if the host operating system is compromised, the key material remains isolated. Remote Attestation provides a verifiable proof that the DPoP signing key is held within a genuine TEE.

A security model that eliminates implicit trust and requires continuous verification of every access request. DPoP is a critical enforcement mechanism within a Zero Trust fabric for agent-to-agent communication. It ensures that even if an agent is inside the network perimeter, it must continuously prove possession of a cryptographic key. The Policy Enforcement Point (PEP) validates the DPoP proof alongside the access token before allowing inter-agent API calls.