Multi-user Authorization #234
Replies: 12 comments 16 replies
-
|
Big plus to this proposal! We encountered the exact same concern of In addition to Wils' proposal, to make MCP Server even more stateless, we can add more variants to the authorization field, to support more auth types required by building Tools with underlying services. MCP Server transparently forwards the auth tokens from client to the underlying service, and relies the underlying service to validate token. For example: In this case, it allow production MCP Server to optionally run with no auth requirements. It runs like an API Gateway, that only does request conversion and forwarding. This could make production MCP servers much more scalable. Regarding Wils' open question:
Why could MCP Client but MCP Server own the token? Think of this story: In some company, Customer Support IT department is developing their Customer Support agent, which needs access to their internal systems.Customer Support department has an existing web based application, application backend server, and have already got the credentials to connect their application backend server to other services (say Order Management service) hosted by other departments. The Customer Support backend server uses API Key to connect to Order Management service. Order Management Service also accepts connections from other department using other API keys. Order Management department wants to build a lightweight MCP Server for everyone, to avoid every single department to build MCP server for order management. Since Order Management department already a service (as an internal API) already, they want make a Order Management MCP Server that everyone inside this company can use. They don't have much bandwidth to implement the MCP Server, and want it to be as lightweight as possible. An OAuth based MCP Server is a bit too heavy - The API Key they've been using for years has already handles the authentication, and the roles associated with the API Key handles authorization. Having OAuth doesn't provide any additional value add. Back to Customer Support IT department, they have API key configured with their backend service. They want to use the same API key to connect to all services provided by the Order management department, including the new Order Management MCP Server. In this case:
We believe that this story happen very frequently across enterprises, and it would be hard for enterprise to implement an extra OAuth layer and additional auth scopes. Making auth requirement optional from MCP server while making MCP a transparent proxy that forwards client tokens would have huge benefit in boosting MCP adoption for enterprises. Let us know what you think! |
Beta Was this translation helpful? Give feedback.
-
|
Requiring that the MCP client has direct access to access tokens/keys to 3rd party services seems like it goes against the point of the MCP server itself issuing its own token — which ensures that the MCP client never has a token that grants direct access to the 3rd party service. This is an important part of the design of the spec, as it ensures that even if the client token is compromised, a bad actor doesn't gain direct access, only access to tools/resources/etc that the MCP server exposes. It does however seem to me like it could sense for MCP tools to be able to specify the scopes they need, or for there to exist some other way for the MCP server to say, "you don't have the right authorization(s) to use this tool" — and then send the end user through the relevant authorization flow to obtain this permission. Another example of this would be #256 – how would a tool call respond with "unauthorized" — and then how would the MCP client know to send the end user through authorization flow? Certainly ways to hack around this in userspace, but does seem like there could be benefit to standardizing this so that clients handle it the same way. |
Beta Was this translation helpful? Give feedback.
-
Agreed -- at a minimum, MCP needs a way for the server to tell the client to send the end-user through an authorization flow at a specific URL. |
Beta Was this translation helpful? Give feedback.
-
Yeah, this makes sense to me too.
Can you expand on this more? I'm not understanding the threat vector here. It seems to me that the client is ultimately the thing that should own the security boundary, since ultimately that's where data will flow to/from (via the MCP server acting in the middle). If the client can't keep an OAuth token safe, it certainly can't keep the user's data safe. As for "the token allowing access only for the resources the MCP server exposes", I think this is solved by the MCP server declaring the required scopes and the service provider issuing whatever scopes are allowed for the client leveraging the MCP server. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@wdawson consider this:
Don't think we want a world where if client token is compromised, this means threat actor has direct access to whatever scopes were granted by the upstream provider. Instead, only the access that the MCP server itself exposes. Raw client tokens of an integration shouldn't be exposed in userspace. This is true of existing integrations platforms, setting MCP aside. If I connect my GitHub account to Cloudflare, the access token that is granted from Github isn't exposed directly to me as the end user. |
Beta Was this translation helpful? Give feedback.
-
|
@irvinebroque totally agree with your points. I'm not suggesting that the token be exposed directly to the user. I'm saying that the MCP client should be in control. Maybe I'm thinking about the MCP client/server differently. I don't see the client as the same as the user or even user-agent. In my head, the MCP client is the "AI agent" with logic, orchestration, access to an LLM, connections to several MCP servers and other tools/functions, etc. Using your example, I'm imagining that Google may offer an MCP server. They aren't going to want to redefine security boundaries and new scopes for MCP. Most likely, they'll think about it as a sort of pass through to their existing APIs and security model. They won't want their server to issue different tokens than their existing authorization server. They won't want that MCP server to have the tokens and manage them on behalf of its clients. They'll want the clients to manage and secure the tokens in accordance with standard OAuth bearer token security practices. It's certainly possible (and likely!) that other folks will create MCP servers that connect to/with Google's APIs. Like you say, there may also be logic contained in that MCP server that narrows the scope of the Google APIs it leverages (e.g. reading email from a particular sender). However, I see two main problems with this:
I agree that it would be nicer to have a world where permissions are more tightly scoped, but I don't think we're there yet. I'd rather meet the industry where it is and enable it to create many more MCP servers by streamlining the developer and user experience. |
Beta Was this translation helpful? Give feedback.
-
|
Supporting separate access levels for tools makes sense. However, I don't think anything is needed to be added to each resource type in the API to do this, and existing standards can be used. (This proposal doesn't really need to refer to anything being "multi-user" since that already is already supported by the OAuth spec. But point taken that part of supporting multiple users is that each user can have access to different tools) My impression is an example way to accomplish this is:
My impression is this is standard and how any OAuth flow would work for any API and does not need anything MCP specific. It could be improved with #195 which could be another way to provide scopes as well. |
Beta Was this translation helpful? Give feedback.
-
|
I think the proposal was edited since my original reply, so i'd like to take an even stronger stance. Strongly against proposals to push OAuth/token handling down into the API details. This was already discussed as part of the authorization spec/discussion proposal and decided against (no real reason to revisit this as the previous principles still stand). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @irvinebroque @wdawson for the insight! So far there are two somehow overlap, but very different user flows. I'd like to clarify about the differences before proceeding with the discussion. MCP Client as End User client (Claude Desktop), MCP Server hosted locallyIn this case, MCP Client act as "something runs together with the end user", like Claude Desktop. Currently this is 99% the case, given most servers are local stdio servers or npx / pypi packages served on stdio (from mcp.so, awesome-mcp-servers in Github, and from the example servers from MCP). Both MCP Server and MCP Client runs on the desktop of the end user. MCP Servers are like Apps we installed on our mobile phone, our VS Code Extensions, or our npm packages downloaded from the npmjs registry. Say the use case for MCP is "A user want's to upload a doc from Google Drive to Claude Chat":
For GenAI User to use Google Drive, they have to get 2 credentials
The problems with this model are:
MCP Client as Intermediate Client, MCP Server hosted remotelyThis flow implies a different journey. Now MCP Client is NOT with the user. Instead, it is an Agent created by a random company with an Agent SDK supporting MCP. Agent is a Python application code sitting on an application server hosted by that company. The MCP Server is no longer the npx/pypi package installed by the end user, it's a HTTP Server hosted internally. On the MCP Server it hosts the tools internally/externally to that company. MCP Servers are like numerous APIs we use from the web. This is the case we envision MCP Servers to get into production. It's not the only way, but should be one of the most common paradigms. Also in this case, per @wdawson
This journey has similar parties, but a very different architecture. Let's say "A user is using Amazon Shopping Agent, and wants to upload a picture they want to search, with a photo from Google Drive"
This has a great user experience:
What should "Auth on MCP Server" protect against?
Agree that MCP Server should have its own OAuth scope. MCP Server hosts Tools, Prompts and Resources, they are all resources and should be carefully protected. Additionally, not all Tools are leveraging existing backends. Some tools may be running complex Python logic, but not talking to any backend services. These tools themselves becomes valuable resources that definitely need to be protected. Thus, if there are indeed a strong need, MCP Server should ask user for an OAuth login so that "User can use the tools provided by that MCP Server (not the consumed services, just the tools)". And per @irvinebroque
I'm not sure if we should store auth tokens on MCP Server. It's great for performance - as caching tokens reduces the need to login every time a tool is invoked. However this also means if a server is compromised, lots of tokens for lots of different services are leaked all at once. Although production MCP Servers are OAuth protected, a carelessly designed MCP Server could still result in token leakage, if the tokens are not properly stored and encrypted. Should MCP Server always ask for an OAuth login?Maybe, but not always. If a MCP Server does have to protect its tools, it must be OAuth protected. However, if a MCP Server simply exposes Tools that are already mature and public and well protected by existing security mechanisms, MCP Server itself should be able to work as a lightweight proxy. In this case, it may not ask for auth, but works as an auth exchange forwarder. The MCP Client owns part of the credentials (say OAuth client secrets), and the GenAI user owns the other part (the password, the token). This grants the maximum safety, as if the token is leaked, it can only be leaked from the end user, and affects just that auth grant to that service. No other services will be affected. As most of the modern services have matured auth protection and expose them as APIs that everyone can access, lots of MCP Servers should work this way. If some, or many tools is a "pass through to the underlying service", why not relying on the existing auth mechanisms from them? Should MCP Server require auth scope?If MCP Server requires OAuth, then yes. If a MCP Server hosts lots of Tools, and the server owner wants a granular access, they can do it both ways:
Auth scope is not the solution, but it's a good enough one to start with. |
Beta Was this translation helpful? Give feedback.
-
|
Great proposal and discussions. There are indeed significant challenges around authorization in multi-user, multi-service MCP agent systems. From an authentication/authorization standpoint, these scenarios represent solved problems in established environments. Enterprise contexts like the sales agent example from @wdawson typically leverage federation and SSO solutions. Consumer environments like Google Drive already implement granular OAuth scopes for varying use cases (https://developers.google.com/workspace/drive/api/guides/api-specific-auth). The core challenge is integrating these existing solutions into the MCP ecosystem. I think focusing on OAuth is a pragmatic first step:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @wdawson and everyone, Great discussion. Handling authorization correctly in multi-user agent scenarios where different users need access to different external services via MCP is definitely necessary for production systems. As the developer of the Ithena Governance SDK ( My perspective:
Overall, I think the proposal to have clients pass necessary external service tokens via Looking forward to seeing how this evolves! |
Beta Was this translation helpful? Give feedback.
-
|
This is interesting from the server development perspective, but it seems to blur the trust boundary between MCP client and server. Ideally, the server would act as an API gateway or passive proxy, but in practice, it can be considered a kind of man-in-the-middle, which could introduce attack vectors, especially with remote MPC servers. When using remote MCP servers, it makes more sense for users to trust the server over the MCP client, since the server is the one accessing user resources. e.g. in OAuth flows, it seems more reasonable for users to consent to the MCP server instead of the MCP client. That way, if something goes wrong, users can revoke access by tracking the server’s ClientId with the auth provider. If we shift this trust to the MCP client (e.g., Claude, Cursor), then by approving access, users are trusting the MCP client to securely handle auth tokens. But based on this proposal, the client may share those tokens with tool developers and servers, which doesn’t align well with OAuth principles. If the MCP server is run by the resource provider (e.g., Google for Gmail), they likely already offer authorization, so it would make sense to host the MCP server behind that existing auth system. This setup simplifies implementations for 3rd-party MCP providers, but those are the entities outside the original resources trust boundary, which in fact need stronger authentication. Also, if this is believed to be the right model, is there a reason auth tokens are sent via _meta in the RPC request instead of standard Authorization headers in the Http request? |
Beta Was this translation helpful? Give feedback.
-
|
@hamidra Good points on the trust boundary risks. My view is the standard The token proposed for This is distinct from how server-side frameworks might inject server/agent-side credentials (e.g., API keys fetched from Vault) needed for the handler's own operations. Those are different credentials with a different purpose and trust model, typically fetched securely on the server side. Putting the external end-user token burden on the client definitely has security implications, but avoids making the MCP server manage potentially thousands of third-party user tokens. It's a trade-off. |
Beta Was this translation helpful? Give feedback.
-
This is the main concern. Security trade offs do not sound good. Also, pushing the OAuth onboarding to the MCP client may not help to solve the underlying problem. Since clients aren’t responsible for providing the tools, they have little incentive to integrate with a wide range of service providers just to support 3rd party tools. A key benefits of MCP is allowing users to bring their own tools. If those tools depend on the client to handle OAuth with target services, many of them may end up unusable. Even if we accept the trade off, a more practical approach might be for the server to handle authentication and then pass the token to the client. This way, the client’s responsibility is limited to securely storing the token per user and including it in each request. |
Beta Was this translation helpful? Give feedback.
-
|
fyi I added a link to this discussion about documenting a convention of |
Beta Was this translation helpful? Give feedback.
-
|
@wdawson — thanks for putting together this discussion. Fine-grained control totally makes sense, and I’d love to see it encompass not just tools but the underlying resources as well. A couple of additional thoughts: Adding _meta for clients & new error codes – really like this; it gives clients a clear contract and room for future expansion. Beyond simple scope – I’m not convinced scope alone will cover cases where different tools need different auth servers. One option is to use /.well-known/oauth-protected-resource/ in two ways: As a single GlobalResource (the current proposal) that applies to the whole MCP. Or allow callers to request a specific resource, e.g. Suggested flow – if the user calls a tool/read resource and receives an auth error, the client could: Hit the relevant oauth-protected-resource endpoint. Unified stdio discovery – could we expose the same /.well-known/oauth-protected-resource discovery endpoint for raw stdio sessions? We have CLI/stdio clients that run over SSH, and giving them an identical discovery path would keep the auth flow consistent across transports. Curious what you (and others) think — especially whether the per-resource option would simplify multi-tenant or mixed-auth setups. Thanks again for driving this conversation forward! |
Beta Was this translation helpful? Give feedback.
-
|
Hey folks! Thanks for all the discussion! After some deliberation with Anthropic and others around the Authorization spec and others, @nbarbettini and I have created the user interaction spec to get a lot of what we think we'll need here. Please check those out! It's not exactly what's in this discussion, but since we now have Authorization, I think the context of this discussion needs to be different if it should continue. I'm going to close this as a result. Thanks again for all the ideas! |
Beta Was this translation helpful? Give feedback.
-
|
@wdawson Circling back on this. I think there’s still a significant open question when the MCP Server is acting purely as a Resource Server and doesn't need to call out to third-party APIs. A lot of the surrounding discussion seems to assume that it does, but that's not always the case. I can see how #475 tackles the delegated access scenario for downstream tools, but what about first-party tools that require their own scopes, even though there's no passthrough involved? Thanks for your thoughts! |
Beta Was this translation helpful? Give feedback.
-
|
For first-party tools, I think that's up to the OAuth implementation! I would suggest using traditional scopes to handle that and/or fine-grained authorization frameworks. Is there something more complicated that causes problems there? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your comment @wdawson! But, I'm still unsure how to handle per-tool access control when the MCP server is acting purely as a resource server. In a typical OAuth-protected API, scope checks happen at the endpoint level. For example, a With MCP, the server’s tools can (and do!) change dynamically. A tool might be registered at runtime, loaded from a plugin, or even created on the fly in the context of a user's session. If the only option is to request a token with a union of all possible scopes, then we are granting the client blanket access to tools that may not even exist yet. That breaks the idea of least privilege and makes it hard to scale secure usage. In a calendar API, you might do this: POST /events
Authorization: Bearer ...scope=calendar.writeDELETE /events/123
Authorization: Bearer ...scope=calendar.adminThat maps cleanly to specific permissions for each action. But in MCP: {
"name": "delete_event",
"arguments": {
"eventId": "123"
}
}There is no stable path or resource name. We just have a tool name and a call payload. If tools are declared dynamically, scopes need to be declared dynamically too. This is where the original proposal from this thread still feels necessary. A server should be able to declare, inside {
"name": "delete_event",
"authorization": {
"method": "oauth2",
"requiredScopes": ["calendar:admin"]
}
}Then at call time, the client provides a scoped token in {
"method": "tools/call",
"params": {
"name": "delete_event",
"arguments": { "id": "abc123" },
"_meta": {
"authorization": {
"method": "oauth2",
"token": "..."
}
}
}
}This lets the server validate the token against the declared scopes, just like a resource server would for a route. The user interaction spec helps for downstream OAuth flows or sensitive prompts, but this case is simpler. The server is the resource. The tool is the resource. The client just needs to know what scopes to send for each tool. Curious if others are running into this and how you’re handling it. |
Beta Was this translation helpful? Give feedback.
-
|
@btiernay got it! Seems like a more dynamic version of protected resource metadata. Definitely curious to see what that could look like. Today, at runtime, the server can issue a WWW-Authenticate response, but it seems like you're pushing (quite rightly I think) for the client to avoid that round trip by knowing what scopes it needs in advance. I'm curious if some of the OAuth enhancements that are coming down the pipe might help to support things like this or if MCP needs a one-off. My sense and preference is that the former would be best for the industry, but the latter might be needed now. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah agreed. The missing piece is how to constrain We’ve been looking at a pattern where each tool declares its own required scopes or claims, and the server enforces them at invocation time. Basically Feels like a gap in both the delegation spec and the resource model it builds on. Maybe it’s not a big issue today since most MCP servers are still just thin wrappers around existing REST APIs, and authorization happens downstream. But in an MCP-first world where tools are the primary interface and REST might not even exist, we need a way to express and enforce tool-level access cleanly. Otherwise, everything collapses to coarse-grained scope checks or brittle conventions. |
Beta Was this translation helpful? Give feedback.
-
|
Curious what the outcome of this was? I'm trying to understand if it's bad practice to pass user session or token information via the |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ChuckJonas we changed the approach after some thought and discussion with the community. We currently have #887 open with our latest direction here. |
Beta Was this translation helpful? Give feedback.
-
|
@wdawson I'm not sure #887 really fits into our approach (maybe it does?). We're running a stateless. A simple sequence diagram of this architecture would look like this: 
Ideally we'd just inject the session/auth headers for each MCP tool call right before flight, but none of the agent frameworks (pydanticai, crewai, etc) really seem to support that. They do however typically let you set the Curious to get your thoughts on this approach or if there is a better way (that doesn't involving rolling full blown oAuth2, IDP, etc) |
Beta Was this translation helpful? Give feedback.
-
|
@ChuckJonas it really depends on your architecture and what you're trying to achieve. As a baseline, all remote MCP servers ( This discussion was opened to figure out how we could secure the channel between the MCP server and the Backend API. Particularly when the Backend API is a third party API, like Google or Salesforce or Slack, for example. In discussing it and arriving at the Authorization spec for MCP, one of the key insights was that the MCP client (PydanticAI) MUST NOT have access to credentials that the MCP server uses to access the third party API. This breaks a host of security expectations from OAuth side and is very dangerous for non-OAuth schemes as well. If, however, your Backend API is your own API (first party), there are various mechanisms you can use to leverage the access token you get from the MCP client. Most commonly, the AS for the MCP server is also the AS for the Backend API. The tokens, however, generally have a tighter audience (limited to the MCP server only). Typically there's a token exchange step that can happen where the MCP server can be stateless and rely on an AS to handle that exchange. I've often seen caching in play for high throughput scenarios. There are other, non-standard ways I've seen this done as well with varying levels of security and risk tolerance. Hope that's helpful! Happy to discuss a specific case further if you'd like. |
Beta Was this translation helpful? Give feedback.
-
|
@wdawson I think that makes sense, but I definitely need to spend more reviewing the MCP Authorization spec and refresh on OAuth. In our case, the Backend API is "first party" as well as the "AS". We are in the process of transitioning to a dedicated authorization/identity service, but right now the Backend API is monolitic and manages both sessions and API requests. I've updated the sequence diagram to better illustrate that. 
I would love to take you up on that in the future, but have some homework to do first. However, if you do see anything blatantly insecure with this approach, please let me know! At a minimum, I think we'll need to add another auth check on the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Your Idea
Proposal: Multi-user Authorization
Hello everyone! I’d like to propose adding tool-level authorization to MCP. This would let servers declare which OAuth scopes a tool needs and let clients pass user tokens at call time. Passing tokens at call time unlocks the ability for MCP servers to be multi-user.
I can open a formal PR, but I want to gather community feedback first to refine the solution.
Background
Recent discussions highlight the need for a clear, standardized way to handle multi-user authorization at the tool level:
We already have MCP Authorization describing how clients authenticate themselves to servers. However, that doesn’t solve tool-level authorization—especially if an agent is acting on behalf of multiple end users who each have multiple OAuth tokens for external services.
For example, imagine a sales agent (as a service) that manages leads, contacts, and opportunities in Salesforce or Hubspot from recordings of Zoom meetings, on behalf of many human end-users (salespeople). Each end-user needs to authorize OAuth connections to those services so the agent can act on their behalf by interacting with tools expressed by MCP servers. These servers ultimately must call the APIs of those services with user-specific OAuth tokens for each end-user.
The key here is that the agent would be both multi-user (it services many end-users), and each end-user could have tokens for multiple external services. The agent may leverage one MCP server that connects to all of those services, or several MCP servers, each connected to a subset of services.
Proposal
1. Tools declare required authorization in
tools/listServers MAY add an
authorizationfield to a Tool schema object:{ "name":"zoom_listPastMeetingParticipants", "authorization":{ "method":"oauth2", "requiredScopes":[ "meeting:read:list_past_participants" ] }, "description":"List the participants of a past meeting", "inputSchema":{ "type":"object", "properties":{ "meetingId":{ "type":"string", "description":"The Zoom meeting ID" } }, "required":[ "location" ] } }method: either"oauth2"(meaning a scoped bearer token is required) or "none" (no token needed). This can be extended with other methods in the future.Note:
"oauth2"here means OAuth 2.0 broadly, including (but not mandating) OAuth 2.1. See the note in step #2 about which flow the client SHOULD implement.requiredScopes: ifmethod == "oauth2", the server MAY include an array listing the OAuth scope(s) needed by this particular tool. Not all services use scopes, so this array MAY be empty.2. Client supplies the token in
tools/callWhen the client wants to call a tool that needs
oauth2authorization, it must first perform an OAuth 2.x flow (which SHOULD be an OAuth 2.1 authorization code flow) to the external service provider. In our example, the client is the agent, which should be knowledgeable about which service providers it ultimately wants to connect to, and therefore should know about the OAuth 2.x authorization configuration of that service provider (i.e. the issuer, authorization endpoint, discovery document locations, etc.).When a token has been obtained for the user, the client includes it in the
tools/callrequest:{ "jsonrpc": "2.0", "id": 42, "method": "tools/call", "params": { "name": "zoom_listPastMeetingParticipants", "arguments": { "meetingId": "5555555555" }, "_meta": { "authorization": { "method": "oauth2", "token": "eyJhbGciOi..." } } } }The
"meta"property is officially described in the MCP protocol schema as a way to allow for additional metadata in the exchange. For now, I’ve included the authorization inside of that property.If
method == "none", the client MAY omit_meta.authorizationentirely; this is identical to the existing behavior oftools/call.The client MAY receive an error from the MCP server indicating a missing or invalid token. Those errors are explored below.
3. Handling missing/invalid tokens
Two new error codes describe tool-level authorization failures:
-32001— no token provided, but the server expected one.-32003— token present but invalid/insufficient (expired, missing scope, etc).These error codes are numbered similarly to HTTP 401 and 403 status codes, but may change in value for the final specification. They follow the json-rpc 2.0 specification for error objects.
Note: Because OAuth tokens vary wildly in composition, the server SHOULD treat the client-supplied token as an opaque string. Error code
-32003does not necessarily distinguish between expired tokens, insufficient scopes, etc. It is the client’s responsibility to provide a valid token.Example error:
{ "jsonrpc": "2.0", "id": 42, "error": { "code": -32003, "message": "Token invalid or insufficient.", "data": { "tool": "zoom_listPastMeetingParticpants", "reason": "Token expired" } } }Design considerations
Q: Why does the client pass a token to the server, instead of the server managing tokens?
A: This adheres to MCP’s ethos of keeping servers focused on their job (tools and resources). If servers also had to store user tokens, they’d need additional state and token management logic. By letting the client handle token orchestration, we keep the complexity on the client side, and the server simply checks for the presence of a token and forwards it with the tool call. It also means that the client can choose to obtain tokens for the end-user at any time–for example, when onboarding a new user to the agent before any call is made to an MCP server.
Q: Doesn’t MCP Authorization already cover this?
A: The OAuth 2.1-based authorization in the spec ensures that a given client is allowed to connect to a particular server. That is separate from authorizing an action on behalf of an end-user, especially when a single agent may serve many different end-users (each with their own tokens). This proposal covers that scenario where the agent needs to acquire authorization from the user to act against a service provider made available through an MCP server.
Q: Why not rely on OAuth 2.0 Token Exchange?
A: Token exchange (RFC 8693) isn’t widely supported by most external services yet. Relying on it would mean devs building today would still have to implement custom solutions for the majority of APIs. This approach instead allows clients to implement the authorization code flow, which is widely supported.
Open questions
Naming: Are
authorization.methodandrequiredScopesintuitive names?Error Codes: Are
-32001(missing token) and-32003(invalid token) sufficient?Next steps
Let me know what you think! If folks agree, I’ll open a PR updating the MCP spec (e.g.,
tools.mdand similar) with these fields, flows, and error code guidelines.Scope
Beta Was this translation helpful? Give feedback.
All reactions