Conversation
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>
|
Thanks for the feedbacck @PederHP
Under what conditions do you foresee an adversary being able to intercept an access token and a DPoP proof (e.g. for remote MCP servers the MCP client/server traffic is expected to be protected by TLS)? This proposal uses DPoP as defined in RFC 9449 to maximize compatibility with existing infrastructure and speed deployment. DPoP sender-constrains access tokens so that only the client that obtained a token can use it. If an attacker steals an access token, for example from an MCP server log, they still cannot use it without also being able to generate a valid DPoP proof. Even if a proof is exposed alongside the token, DPoP proofs are short-lived, which greatly limits replay risk. Deployments that need stronger replay protection can require a fresh proof via the nonce mechanism described in the PR. This can be implemented statelessly and provides a per-request proof without the overhead or retooling of existing infrastructure of signing full messages. Depending on deployment needs, fresh proofs can be required for every call or only when triggered by risk-based policy.
Thanks for pointing that out, please feel free to suggest alternative text. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
1 similar comment
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
|
Hey @PieterKas looking into this, would you mind adding an optional definition for body-signing for stateless cases that aren't willing to accept time window based replay prevention? ala the earlier suggestion My proposal would OAuth Protected Resource Metadata can be extended to claim dpop support and also potentially body-signing as a requirement. If absent it can default to the RFC behaviour with no extra cost. In a nutshell offering flexibility. The use-case is essentially for a multiplexing gateway that is untrusted itself and may permit replay attacks- a client could "trust" this gateway if the onwards MCP required & enforced dpop. Timing is insufficient as the gateway by definition is on the request flow so can seamlessly modify contents. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 14 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
@nickcoai - I am not sure I follow your use case. The usage of DPoP in this SEP is constrained to the interaction between the MCP Client, OAuth Authorization Server for the MCP Server and the MCP Server. DPoP constrains the token to the MCP server it is accessing. A DPoP constrained token should not be forwarded to another MCP server and if it does, the receiving MCP server should not accept it since the original token was not intended for it. If the MCP client does not trust the MCP server, but it does trust another MCP server, it should obtain a DPoP constrained token for the MCP server it trusts and use that token. Can you clarify more about the reasons for deploying an untrusted MCP server as a middleman between MCP Clients and trusted MCP servers, and why the MCP client would not request an access token for the MCP server it actually trusts in this flow? |
Made updates reflecting feedback in comments.
|
I want to revisit this and see what it would take to make this an official auth extension, similar to what we've done with client credentials. @pcarleton thoughts? |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 20 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
1 similar comment
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 20 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 20 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
|
Hi, I'm currently reviewing this SEP (including the dpop-extension draft) and the modelcontextprotocol/conformance#395, modelcontextprotocol/conformance#396 PRs. So far it's looking solid, although the conformance suite seems to be ahead of the spec. What I've found so far in terms of inconsistencies is:
There might be more inconsistencies, and since I don't have access to the https://ant-mcp-oss.slack.com Slack I'm not sure if any of these have already been discussed in there. In any case, I hope this helps 🙂 |
|
|
||
| [RFC 9449 Section 11.1](https://www.rfc-editor.org/rfc/rfc9449.html#name-dpop-proof-replay) provides specific guidance on replay protection mechanisms that adress the risks of a DPoP Proofs being replayed. | ||
|
|
||
| MCP servers that is not capable of keeping state or perform global `jti` tracking provides DPoP proof replay protection by enforcing short `iat` acceptance windows of +/- 5 minutes and standard RFC 9449 claim validation. A stateless MCP server may provide additional replay protection by using a server supplied nonce as defined in [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449) (e.g. by using an encrypted timestamp as the nonce value which can be decrypted, parsed and verified to be within an acceptable time window when returned in DPoP Proof) (e.g. by encrypting a timestamp using an Authenticated Encryption with Associated Data (AEAD) scheme which can be decrypted, parsed and verified to be within an acceptable time window when returned in DPoP Proof). |
There was a problem hiding this comment.
If the nonce is implemented as an encrypted timestamp then that same nonce value will be valid for all clients that interact with a MCP server over a given time period. I can't immediately think of an attack that multi-client nonces would help enable:
- Pre-generation is still impossible for the client since it cannot perform encryption of the nonce
- Replay protection is unaffected - the nonce affects the server-accepted lifetime of the DPoP proof, not its ability to statefully track replay
Nonetheless, it strikes me as odd for the nonce used in sender-constraining tokens to clients to not itself be constrained to a client. Is this a problem worth solving? Am I overthinking it? One solution - a server could also encode the client ID in the nonce as well - ENC(CONCAT($client_id, "|",$timestamp)) - to create a unique nonce per client per time period.
There was a problem hiding this comment.
Thank @max-stytch - It would be good to understand the threat you have in mind (designing countermeasures without defining the threat invites complexity without clear benefits).
To my knowledge this is not something that has come up for OAuth in general, which makes me hesitate on whether this is worth solving. Is there something about how MCP uses OAuth that would create a risk here?
Your idea is a clever way to make timestamped nonces unique and specific to a client when interacting with the Authorization Server. I don't believe the Resource Server in OAuth typically has knowledge of the client_id though. However, if timestamps are not sufficiently unique, it could be salted or additional information could be added (e.g. a session identifier if it exists etc) if a deployment needed it.
In terms of the specification, how the nonce is construsted is not an interoperability issue (only the server needs to know how to handle the nonce when it receives it back), so we can provide guidance, while still leaving implementers with options on how they implement the nonce.
|
|
||
| [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449) already provides the core security properties for sender constraining OAuth Access Tokens. When combined with TLS transport-layer security and appropriate token and proof lifetimes, these mechanisms are sufficient to significantly reduce the risks associated with token exfiltration and replay in MCP deployments, even if the MCP server is not capable of maintaining global state. | ||
|
|
||
| ## Backward Compatibility |
There was a problem hiding this comment.
I would appreciate a section explaining how MCP Servers and Client should work with WWW-Authenticate headers, for both DPoP + DPoP/Bearer backwards compatibility situations. 9449 describes the scheme but MCP makes heavy use of WWW headers for scope negotiation, and there are many existing client libraries that probably won't play well with MCP servers accepting both token types. I assume a header would look something like the following?
POST /mcp HTTP/1.1
Host: mcp.example.com
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer, DPoP algs="ES256 PS256",
resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
scope="files:read"
Showing how scope negotiation + PRM + DPoP upgrades work together in one place would be very helpful.
There was a problem hiding this comment.
Thanks @max-stytch - to what extent can we just rely on the PRM doc to advertise whether DPoP is required (or not) and what algorithms it supports rather than having a negotiation via headers? RFC 9728 already specifies both dpop_signing_alg_values_supported and dpop_bound_access_tokens_required (which we should make mandatory in this SEP)?
Is the case your thinking of specifically when a MCP server supports both DPoP and Bearer, and the client only supports one or the other?
Maintainer Activity CheckHi @D-McAdams! You're assigned to this SEP but there hasn't been any activity from you in 20 days. Please provide an update on:
If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer. This is an automated message from the SEP lifecycle bot. |
|
@oxcabe - thanks for your review - you are correct, the two documents have drifted and needs to be reconciled. Thanks for pointing to specific gaps. Much appreciated. |
This branch has not been deployed
10 participants
Motivation and Context
This extension defines DPoP (Demonstrating Proof-of-Possession) support for the Model Context Protocol, enabling sender-constrained access tokens that prevent token replay attacks. This extension builds upon the baseline authorization requirements defined in the main Authorization specification.
DPoP binds access tokens to a cryptographic key pair controlled by the client. When accessing MCP server resources, clients must prove possession of the private key by providing a signed proof with each request. This prevents unauthorized use of tokens even if they are intercepted or leaked.
How Has This Been Tested?
TBD
Breaking Changes
No
Types of changes
Checklist
Additional context
For inclusion as an auth extension
@D-McAdams