DPoP
DPoP is an OAuth security mechanism that binds access tokens to a client's asymmetric key pair. On each request, the client must attach a proof JWT signed with its private key, preventing stolen tokens from being reused by unauthorized third parties. The standard is defined in IETF RFC 9449.
Timeline (last 90 days)
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.
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.
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).
For existing MCP deployments, a gradual migration is recommended: first support rather than enforce DPoP, observe client adoption, and then progressively tighten the policy.
If the client ecosystem does not yet support DPoP, forcing it to be enabled may cause connection interruptions.
DPoP (Demonstration of Proof-of-Possession) is defined by RFC 9449 and is an extension mechanism designed for OAuth 2.0 in which the client generates a short-lived DPoP Proof JWT for each request, binding the access token to a specific client key pair.
DPoP is a patch layered on top of OAuth 2.0's existing Bearer token system, whereas GNAP builds key binding as a first-class citizen of the protocol from the ground up.
All Facts (8)
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.
50%UnverifiedDPoP 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.
50%UnverifiedA 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.
50%UnverifiedWith 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).
50%UnverifiedFor existing MCP deployments, a gradual migration is recommended: first support rather than enforce DPoP, observe client adoption, and then progressively tighten the policy.
50%UnverifiedIf the client ecosystem does not yet support DPoP, forcing it to be enabled may cause connection interruptions.
50%UnverifiedDPoP (Demonstration of Proof-of-Possession) is defined by RFC 9449 and is an extension mechanism designed for OAuth 2.0 in which the client generates a short-lived DPoP Proof JWT for each request, binding the access token to a specific client key pair.
50%UnverifiedDPoP is a patch layered on top of OAuth 2.0's existing Bearer token system, whereas GNAP builds key binding as a first-class citizen of the protocol from the ground up.
50%