Demonstration of Proof-of-Possession (DPoP)

DPoP cryptographically binds an access token to a public-private key pair held by the client. The client generates a DPoP Proof JWT signed with its private key, which the resource server validates against the public key embedded in the proof. This ensures that even if a token is exfiltrated via a Man-in-the-Middle (MITM) attack, it cannot be replayed without access to the private key.

To prevent an attacker from capturing and reusing a valid DPoP proof within its validity window, the protocol employs a server-issued nonce (a unique, single-use cryptographic number). The resource server can challenge the client with a fresh nonce via a DPoP-Nonce header, requiring the next proof to incorporate it. This makes every proof effectively single-use and resistant to replay.

The DPoP proof contains an ath (access token hash) claim, which is the SHA-256 hash of the access token value. This creates a direct cryptographic linkage between the proof and the specific token it is authorizing. The resource server verifies this hash to confirm the proof was generated for that exact token, preventing an attacker from using a valid proof with a different stolen token.

DPoP is designed to protect all standard HTTP methods used in API communication. The proof must include the full target URI and the HTTP method (e.g., POST, GET) in its claims. This prevents a captured proof intended for a read-only GET /api/status endpoint from being maliciously replayed against a destructive DELETE /api/agents endpoint, a classic Confused Deputy Problem mitigation.

DPoP leverages the RFC 7800 framework for Proof-of-Possession Key Semantics. The authorization server binds the client's public key to the issued access token, often embedding a cnf (confirmation) claim containing the JWK Thumbprint. This allows resource servers to independently verify that the presenter of the token is the same entity that authenticated to the authorization server, establishing a strong Workload Identity.

Resource servers do not need to maintain a session state for DPoP validation. They verify the proof's signature using the embedded public key (jwk), check the ath claim against the presented token, and validate the nonce. This statelessness makes DPoP highly scalable for distributed Zero Trust Architectures (ZTA) where centralized token introspection is a bottleneck.