Repository navigation
[Authorization] Support token exchange protocol for clients that do not interact with the user #20
Description
Activity
I think this would be a valuable addition, but I'd say this would be more of a general guideline for implementers (i.e., documentation) rather than a spec update. There's a small change that the auth crew was working on that will document the server-to-server interaction, and maybe that's something we can bundle there.
Hi @localden thanks for responding - I wouldn't mind if this is more documentation than spec update. Would that mean these recommendations would reside in the security-best-practices doc? or somewhere else?
Curious what is meant by server-to-server interaction? Which servers?
For use-cases where clients do not interact with users, typically you would use OAuth 2.0
client_credentialsgrant-type. Alternatively, if you are passing aroundaccess_tokenson the backend, your client can be smart enough to "just use the token" when making API requests.Custom MCP client can literally do anything one can imagine to get an
access_token. AI tools are inflexible right now, so that's why people are asking questions like this. You typically have no real control over how a commercial AI tool behaves with regard to its MCP support.I have used Token Exchange extensively. If you use it, it is simply part of your backend infrastructure. On the edge of the network, you might only expect to see OAuth access tokens from your primary OAuth issuer/tenant. However, within your cloud infrastructure, you can freely use something like Token Exchange to issue new tokens with mutated claims (e.g., scopes).
Moved to
ext-authsince this is likely something that can be either an extension, or covered through docs (in which case, we will need a separate docs PR).One distinction worth splitting in the guidance: "no user interaction" covers two cases with different identity outcomes.
If there's genuinely no human anywhere in the chain,
client_credentialsor exchange to a service identity is the right answer. But if a human authorized the agent upstream and this hop is just non-interactive, collapsing to a workload identity drops the accountability link. You can prove the bot called the tool; you can't prove who directed it. That gap is invisible until an audit or an incident actually needs the trail.RFC 8693's actor semantics are designed for this:
substays the authorizing human,actcarries the agent, and attribution survives the exchange. The claim shape is the decision, not the exchange mechanism itself.If it lands as docs (which sounds right per @localden's read), worth making that split explicit, and pointing at ID-JAG (
oauth-wg/oauth-identity-assertion-authz-grant) as the standardized on-behalf-of shape for the human-upstream case — otherwise implementers default to flattening everything toclient_credentialsand lose the person in the process.
Is your feature request related to a problem? Please describe.
The current Authorization Spec draft focuses many details on a client that performs the login itself with Authorization Code Flow + PKCE. I see use cases where the client would not interact with the user, and instead the host application receives an access token from some other application that has been granted access to the host app on behalf of a user.
When this happens, it seems Token Exchange is the proper method to obtain a new access token meant for the MCP Server. I wonder if there needs to be some way for a client to know the expected value of the MCP Server's audience claim. I'd like to open discussion surrounding this use case.
Describe the solution you'd like
I wonder if there could be a section in the Authorization spec dedicated to this use case. Evidently the token validation in this case would need to be performed by the Host application instead of the MCP Client (which I'm not sure is in the scope of this spec?). However, the token exchange is something that I believe should fall to the MCP Client if in other cases the MCP Client is responsible for handling the login.
Given this affects the implementation of an MCP Client, I believe this belongs in the main authorization spec.
Describe alternatives you've considered
If this is perhaps not meant for the main authorization spec, I feel this is a common enough pattern at least worth a mention in the security-best-practices doc.
Additional context
This issue is semi-related to modelcontextprotocol/modelcontextprotocol#214 but is a slightly different (maybe broader) use case.
Also having been watching the open PR modelcontextprotocol/modelcontextprotocol#408 possibly there should be some discussion of token exchange by the server to downstream tool, but perhaps that use case discussion can belong in another issue.