DPoP

DPoP binds the identity of the token holder, not who the token holder acts for or what task they perform.

For AI agents connecting to systems, using RAR and DPoP in combination is currently the more pragmatic choice.

None of the four extensions provides a unified answer for scenarios such as permission downgrade during refresh of long-running tasks and task interruption recovery.

Even when combined, the four OAuth extensions still cannot express cross-agent delegation chain traceability in a standardized way.

DPoP does not rely on mutual TLS, so its deployment threshold is lower than that of mTLS-bound certificate schemes.

The standard DPoP specification (RFC 9449) covers both access tokens and refresh tokens, whereas Google's current choice is to mandate binding only for refresh tokens, with access tokens still being Bearer.

Google recently introduced a DPoP (Demonstrating Proof of Possession) binding mechanism for OAuth refresh tokens, binding refresh tokens to client keys while access tokens remain in Bearer form.

When issuing a token, the authorization server embeds the fingerprint of the client's public key (jkt) into the token (usually via the cnf claim); when using a refresh token to exchange for a new access token, a valid DPoP proof must also be provided, and the server verifies the signature, the jkt match, and the consistency of request parameters.

RFC 9449 (OAuth 2.0 Demonstrating Proof of Possession) is a standards specification published by the IETF that defines the complete DPoP framework, including binding for access tokens and refresh tokens, the nonce mechanism, error responses, and more.

Google's DPoP support targets clients that can securely hold private keys, such as server-side applications and native applications (using secure storage); for public clients that cannot securely store keys (such as pure browser-side applications), DPoP's applicability is limited.

The main steps to implement DPoP include: generating an asymmetric key pair, attaching a DPoP proof (JWT) to the refresh token request, and ensuring the token endpoint verifies that proof.

The DPoP proof is bound to the request, and developers need to ensure time synchronization and correct nonce handling to avoid replay attacks.

DPoP's protection of refresh tokens reduces the scope of impact after a token leak, but access tokens remain Bearer, and an access token leaked within its validity period can still be abused.

The client's key management itself becomes a new attack surface; if the private key is not properly protected, DPoP's benefits will be greatly diminished.

DPoP is a mechanism defined by the IETF OAuth working group, in which the client generates an asymmetric key to sign each HTTP request and the resource server verifies the signature, so that even if a token is stolen, an attacker without the private key cannot use it.

If the client ecosystem does not yet support DPoP, forcing it to be enabled may cause connection interruptions.

DPoP is a mechanism that binds tokens to client keys, requiring the client to sign each request with a private key to prove possession of the bound key.

A DPoP proof is a JWT signed by a private key, containing the HTTP method, target URL, timestamp, and unique random value jti, with the client's public key fingerprint bound at the time of token issuance.

For existing MCP deployments, a gradual migration is recommended: first support rather than enforce DPoP, observe client adoption, and then progressively tighten the policy.

With DPoP enabled, the MCP server needs to verify the DPoP proof header while validating the access token, and must be capable of parsing signatures, verifying key binding relationships, and preventing replay attacks (via nonce or timestamp).