Sender-Constrained Tokens in MCP, implemented through DPoP (Demonstrating Proof of Possession), is the OAuth security pattern that binds an access token to the specific client that obtained it. Defined in RFC 9449, DPoP requires the client to sign every request with a private key bound to the token. Even if an attacker steals the token, they can’t use it without the matching private key. OAuth 2.1 pushes sender-constrained tokens wherever possible, and the MCP specification calls them out as the strongest defense against token theft. Bearer tokens, the default in most MCP deployments today, fail this test: anyone holding the token can use it, from any client, anywhere.
How DPoP Works in MCP Request Flows
The MCP client generates an asymmetric key pair (typically ECDSA P-256 or RSA-2048) at startup and sends the public key as a JWK thumbprint when requesting a token. The authorization server binds the token to that key by including a cnf (confirmation) claim with the thumbprint. For every subsequent request, the client signs a DPoP proof JWT containing the HTTP method, target URL, and timestamp, then sends it in a DPoP header alongside the access token. The MCP server validates the DPoP proof signature against the public key in the token’s CNF claim. Mismatched proofs get rejected immediately.
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why DPoP Is More Relevant for MCP Than Most APIs
MCP clients often run on user laptops, in containers, or in CLI environments where token theft is a real risk. Bearer tokens stolen from these environments work anywhere, against any client. DPoP-bound tokens are useless to anyone except the client that originally requested them because they require the private key the original client holds. Token theft becomes worthless. The OAuth 2.1 specification explicitly recommends sender-constrained tokens, and the MCP authorization spec aligns with that recommendation. For high-risk MCP deployments (financial data, healthcare, code repositories), DPoP is the right baseline, not Bearer.
How to Implement DPoP Correctly in MCP
Generate fresh key pairs at client startup, store private keys in OS-native secure storage (Keychain, Credential Manager, Secret Service), and rotate keys on a regular schedule. Use ECDSA P-256 or RSA-2048 for compatibility with most authorization servers. Include accurate HTTP method, URL, and timestamp in every DPoP proof. Reject DPoP proofs with stale timestamps to stop replay. On the server side, validate the signature, thumbprint match, and replay protection on every request.
Summary
Sender-Constrained Tokens via DPoP (RFC 9449) bind every MCP access token to the specific client’s private key, turning stolen tokens into useless artifacts that can’t be replayed by attackers. For high-risk MCP deployments, DPoP should be the default. The Certified MCP Security Expert (CMCPSE) certification trains engineers to implement DPoP correctly and design MCP architectures where token theft no longer means breach.