I'm not sure I understand how this works. Could you go through a step by step example of the requests and responses that we would see with this?

Doesn't the new authorization work that was proposed handle this with headers? I might have misunderstood the original proposal, but I thought you could 401 with a header that pointed you to an auth server to auth with, but I might be mis-remembering

Doesn't the new authorization work that was proposed handle this with headers? I might have misunderstood the original proposal, but I thought you could 401 with a header that pointed you to an auth server to auth with, but I might be mis-remembering

@patwhite that is for when authorization is needed for the client to communicate (at all) to the server. This proposal is for any situation when a server would want to interact with the user. For example:

• A productivity MCP server might request a user to authorize a third-party service to
  access their documents. <-- This is different than the authorization required for the MCP client to talk to the MCP server
• A news MCP server might request a user to upgrade their subscription to access more features.
• A banking MCP server might request a user to verify their account to access a new feature.
• A media MCP server might request a user's favorite music genre to personalize the user
  experience.
• A social media MCP server might request an image to use as a profile picture.

I'm not sure I understand how this works. Could you go through a step by step example of the requests and responses that we would see with this?

@aaronpk the Flow Diagram sections of the spec show the MCP protocol level requests at a high level. You'll notice the "Human interaction" note, which could be anything, similar to the "user authenticates" part of the OAuth authorization code flow. In this case, the "human interaction" might be an OAuth flow that redirects to the MCP server, granting it a token to call some OAuth protected API downstream. Or it could present a form asking for an API key. Or it could present a stripe payment portal requiring a subscription upgrade. The main point here is that the MCP spec doesn't need to care what the interaction is.

Does that help? Are you looking for a flow diagram for a specific use-case to ground understanding with an example?

Doesn't the new authorization work that was proposed handle this with headers? I might have misunderstood the original proposal, but I thought you could 401 with a header that pointed you to an auth server to auth with, but I might be mis-remembering

@patwhite that is for when authorization is needed for the client to communicate (at all) to the server. This proposal is for any situation when a server would want to interact with the user. For example:

OK, got it - I think this is a cool idea, and solves some issues in the protocol in general. But, I do worry about conflating generalized interactions with security specific interactions. For generalized interactions, I think it would be great to actually flesh this out ever further, add some additional details around multi-turn interactions etc.

But, for a security demand in particular, this PR could literally just be a single new error type (401 equivalent) that includes enough information to craft an oauth redirect. That could be a lot easier to generally get through the review process here, and I think it would also be a lot easier to get clients to implement it, cause it would be using mechanisms which already exist, and you could basically make it more or less required for the vNext spec.

But, for a security demand in particular, this PR could literally just be a single new error type (401 equivalent) that includes enough information to craft an oauth redirect. That could be a lot easier to generally get through the review process here, and I think it would also be a lot easier to get clients to implement it, cause it would be using mechanisms which already exist, and you could basically make it more or less required for the vNext spec.

This is a good point @patwhite. That is exactly what we've defined under "Requiring Interaction as an Error Response".
I'd be happy to split just that part out into a small, focused PR. But, it depends on many of the ideas in the rest of the proposal, so it'd need to bring at least the ua interaction type along with it.

FYI, I slimmed down this PR (thanks for the nudge from @patwhite) to focus just on the necessary interaction to unblock authorization. The language is written with an eye to extending the user interaction concept in the future, if desired.

I also added more flow diagram examples, let me know if it feels clearer now @aaronpk!

Thanks for drafting this proposal. I have two follow-up questions:

1. Interaction monitoring & callback mechanics
   Could you clarify the expected completion patterns (server-hosted callback) and what data, if any, the client must relay back to the server?

2. Error handling & corner cases
   Will the spec define standard result / status values (e.g., completed, cancelled, timeout, error)?
   How should user-initiated aborts (for example, an OAuth error=access_denied) be surfaced?

@adranwit thanks for taking a look! Answers inline:

Could you clarify the expected completion patterns (server-hosted callback) and what data, if any, the client must relay back to the server?

The MCP client doesn't need to relay anything back to the server. The client's only responsibility is defined in "Interaction Types > User Agent Interaction":

The MCP client MUST facilitate the opening of the URL in a User Agent.

That's it! The rest of the interaction is controlled by the MCP server, and purposefully kept out of view of the MCP client. That maintains the correct security boundary around the MCP server.

Of course, in a interaction like a downstream OAuth authorization, the MCP server will indeed host a callback to complete the authorization flow. But again, that's not in view of the MCP client.

Will the spec define standard result / status values (e.g., completed, cancelled, timeout, error)?

I think a progress mechanism that gives the client updates on the status of the interaction would be a good addition. I've left it out of this proposal (for now) to keep this focused specifically on the absolute must-haves to unblock use cases like downstream tool authorization. Progress could be added as a fast-followup, or now if the community feels it is a must-have.

How should user-initiated aborts (for example, an OAuth error=access_denied) be surfaced?

The end-user cancelling or denying the interaction at the outset is addressed in "Client-Initiated Cancellation".

But you raise a different, interesting scenario: the user proceeds partway through an authorization flow (for example), and then rejects it in the downstream system. This is still out of view of the MCP client by definition, unless the MCP server chooses to indicate to the client that the entire interaction should be considered canceled. In that case, the cancellation notification described in "Server-Initiated Cancellation" is appropriate.

Added a concrete example (plus flow diagram) above of the tool authorization scenario, by far the most requested version of this idea!

Thanks for adding the concrete example and flow diagram @nbarbettini —super helpful!

The sequence reads like a classic variation of Backend-for-Frontend (BFF) OAuth flow:

1. The MCP server generate authorization URI.
2. The MCP client launches the user-agent with authorization URI.
3. The third-party authorization server redirects back to the MCP server.
4. The server redeems the code/token.
   Correlation is already handled by the OAuth state parameter.

All that said, applicability is far beyond OAuth flows, especially when the MCP client is effectively out-of-band for the secure exchange.

Idea: instead of layering another “correlationId”-style value on top of state or other key per interaction, should the MCP spec allow an explicit interaction-completed callback (POST) on MCP server?

• The server already knows the redirect URI and session id, interaction request id; it could include the session ID/interaction request id, plus the payload it needs (e.g., auth_code) in that callback.
• The MCP server would just wait for the callback (or timeout), avoiding the need to pass the auth code back on URL via regular GET redirect.
  I’ve always been wary of auth code or other secret log-leak (not real issue with PKCE though), for these, I've experimented with a localhost-redirect BFF variant (discussion #483)

Would love the team’s thoughts on whether a POST-back (or similar out-of-band signal) callback could simplify the flow.

Thanks again—this example really clarifies the proposal!

@wdawson

Regardless of whether or not you want to specifically build in-band E2EE primitives, I think there are use cases (anti-abuse, access policy, monitoring, etc) that are going to want the chain of actors to be auditable and provable. So you're going to want cryptographic identity as part of the MCP spec (and any other related specs, like A2A), so that a service E can know it's being called from User A > Agent B > Agent C > Service D.

Gotcha. I want to decouple this PR from any details about chaining MCP servers and how that needs to work securely. I was entertaining the discussion earlier so as to illustrate that it's possible and how I could see things working in the current state. But I agree there are many details to work out as far as verifiable identity beyond each server being a different OAuth RS (and/or client in the chaining case). Are you good with pulling that discussion out of this PR? Or is there a critical piece I'm missing as to why it's a prerequisite to user interaction?

Absolutely fine to move that conversation elsewhere, and happy to refocus this conversation on the User Interaction primitives. I only brought it up because we started talking about in-band E2EE, impersonation, MITM, etc. Can you suggest a good venue for secure chained agent/service identity mechanisms? I see it best fitting in with MCP Initialize, I suppose?

@chhamilton

Absolutely fine to move that conversation elsewhere, and happy to refocus this conversation on the User Interaction primitives. I only brought it up because we started talking about in-band E2EE, impersonation, MITM, etc. Can you suggest a good venue for secure chained agent/service identity mechanisms? I see it best fitting in with MCP Initialize, I suppose?

I did a quick search in the Discussions in this repository and found this one that might be a better fit from @ggoodman , but you could also start a new Discussion if you'd like.

@LucaButBoring

Given that impersonation is discussed in the spec, I think it is important to discuss seriously here, or at least to amend the proposed spec to clearly outline what is currently in- and out-of-scope regarding impersonation for this proposal, and/or to go into more detail on the recommended mitigations for it in the security considerations section of the spec.

Definitely fair. I think we'll need to disambiguate "impersonation" and whether that's the user level or MCP client level. Thanks for your comments here. We already had on our list to clean up that section of the spec and this will help I think!

I'm not sure what you mean here. An MCP server has no reason to return a pre-signed URL as the interaction URL. The interaction URL is meant, effectively, to be a challenge to a user, not a credential. We can clarify that in the spec.
But if you mean that an MCP server might issue an interaction request and then ask for a pre-signed URL to get access to some data (in an S3 bucket for example), that's fine. But there are MITM issues with receiving data in this way, as I think you indicated in your 3rd point. OAuth has mitigated many of the problems that arise out of essentially sharing your password (or one time token) with another service.

I was actually referring to the former case - user interactions come across as general enough that sending a pre-signed interaction URL seems like a conceivable use case (maybe exposing a non-anonymous, non-OAuth-guarded form or something that I need temporary access to but don't want intermediaries to intercept). If that's explicitly not desired and this isn't intended to be general-purpose, secure out-of-band communication, that's fine but should be specified, or the assumptions under which it is secure should be stated explicitly in a separate section.

Definitely will make this clearer! The intention for interaction URLs is to provide a mechanism by which the MCP server can communicate directly with the user. That URL will be visible to the MCP client and therefore MUST NOT contain any sensitive or secure information directly. Again, we don't want to be prescriptive about the interaction itself here, but you could imagine that once the user agent loads that URL, the server could reveal the pre-signed URL to that user. There might be some level of authentication (e.g., checking a session) before that happens if desired as well.

The problem goes both ways, at any rate - if the interaction URL itself is delivered through a proxy, intermediaries can override it; and if the end-user fills data into that proxied interaction URL, that's vulnerable to being exfiltrated by an intermediary that has overridden the proxied interaction URL. In the auth challenge scenario where GT issues a challenge to request authorization to do more than the token from PA->GT allows, that is vulnerable to being intercepted by PA to instead grant PA permission to perform that same action.

I think this is really just going back to the unaddressed comment from @localden about what exactly it means to verify server authenticity to avoid phishing attacks (in hindsight that is effectively what I was describing).

Yeah, we'll need to detail this a bit more as well. Thanks for the nudge here!

@nbarbettini - thank you for putting this proposal , i have no role in the review process but would like to share my thoughts as someone handling auth for the past 15 years now.

1. Resource servers (in our case MCP servers) - needs to be kept simple, just like a simple API server that only knows to validate some auth headers sent along with request to API. this means does NOT have callback endpoints etc. its the responsibility of the caller to obtain the proper access token.

2. In your flow diagram step 2 the "Server determines user is not yet authorized" - how exactly ? does it needs to manage sessions now ? (resource servers are usually stateless) , what the client need to send so the server knows this user already authorized ? this brings a lot of burdain to the resource server (specially if its a cluster of nodes)

3. You say the client is not confidential - why ? maybe claude desktop is not , but many applications and clients are written as part of a web application which is confidential .
   the client does not run in browser code , it usually part of the message loop an agent manages on some backend process.

I admit that in this MCP world i'm quite a beginner and probably haven't thought this through all use cases (although downstream auth is definitely interesting to me)
but according to the spec of 2.1 with Dynamic Client Registration , it feels like the MCP client is the client
(hosting callbacks, clientIds, secrets , exchanging codes with tokens etc) and it sole purpose is to navigate messages between LLM request and MCP server tools , taking care of authorization while doing so.

this way downstream auth is made simple in the eyes of the MCP server , you either send me a token or get 401 asking you to issue one, then come back.

@aaronpk - would love to hear what do you think as well.

@shlomiken Thanks for taking a look!

1. Resource servers (in our case MCP servers) - needs to be kept simple, just like a simple API server that only knows to validate some auth headers sent along with request to API. this means does NOT have callback endpoints etc. its the responsibility of the caller to obtain the proper access token.

Resource server is one of the roles that an MCP server plays, but not the only role. This proposal enables the MCP server to take the role of OAuth Client for any downstream resource servers it needs to access.

2. In your flow diagram step 2 the "Server determines user is not yet authorized" - how exactly ? does it needs to manage sessions now ? (resource servers are usually stateless) , what the client need to send so the server knows this user already authorized ? this brings a lot of burdain to the resource server (specially if its a cluster of nodes)

MCP servers that act as OAuth clients to downstream services need to be stateful. It's implied but not stated explicitly in the text of this proposal - I can call that out more clearly.

3. You say the client is not confidential - why ? you don't trust claude desktop (as an example) to not steal your credentials , if so don't install it , just like you trust google when you install chrome to not steal your passwords .
   the client does not run in browser code , it usually part of the message loop an agent manages on some backend process.

In the language of OAuth 2.1, Claude Desktop is a public (not confidential) client. SPA code that runs in a browser is public as well. If the MCP client code does indeed run entirely on a server-side/backend process, then it qualifies as confidential.

The distinction between public and confidential is not about whether I trust Claude Desktop or not. It's whether I can decompile or right-click->View Source. If I can, then a malicious actor can too, which means we need to treat the client differently from a security perspective. For example, we can't keep OAuth client secrets safe anywhere in a public client.

it feels like the MCP client is the client (hosting callbacks, clientIds, secrets , exchanging codes with tokens etc) and it sole purpose is to navigate messages between LLM request and MCP server tools , taking care of authorization while doing so.

this way downstream auth is made simple in the eyes of the MCP server , you either send me a token or get 401 asking you to issue one, then come back.

This is tempting, and it's where I started first. I landed on the current proposal after conversations with @wdawson, @aaronpk, @mcguinness and others.

The reasons the MCP client can't also be the client to the downstream OAuth service are:

1. It risks token exfiltration. If the MCP client (which in many cases is a public client) ends up holding tokens for many downstream services, the tokens can easily be exfiltrated. On the other hand, if the tokens are kept secret on the MCP server and not shared with the MCP client, they cannot be exfiltrated.
2. It risks token misuse. When an MCP server talks to a downstream API, it may need to impose additional security constraints (or rate limits, validation, etc) on the request. If the MCP client holds a real token for the downstream API, it can bypass any constraints imposed by the server and talk to the downstream API directly.
3. It breaks the security boundary clearly defined by MCP authorization. This is also explicitly discussed in the Security Best Practices page under Token Passthrough.
4. It burdens the client with a lot more complexity. Besides requiring callbacks, token exchanges, etc. it requires the MCP client to store client secrets (which makes all public clients, e.g. Claude Desktop incompatible with this feature), or requires the client to perform DCR to every OAuth service the MCP server wants to access (which is not possible for many popular services today).

Thanks for this proposal, how would the following work with this solution?

I have an MCP server that can perform various levels of sensitive actions. Let's use the Github MCP server as an example. It can make commits on a personal and corporate repo.

The MCP server has permission to carry out all of these actions because the user has that level of permission. I want to user to be prompted by default above a certain level of sensitive action - but to give them a way to say "next time I do this, I don't want to be prompted"

For example, I want them to be prompted for any time they're performing mutation actions against the corporate repo - unless they have decided that it's fine for repo X. However, I want them to be always prompted if they're changing security settings for any repo

For example, I want them to be prompted for any time they're performing mutation actions against the corporate repo - unless they have decided that it's fine for repo X. However, I want them to be always prompted if they're changing security settings for any repo

@RichardoC, I think there are tools emerging that help address your use-case. For a naive consent prompt, perhaps Elicitiation will suffice. However, if you want stronger signals and better 'receipts', you might reach for this proposal.

Your sensitive tool calls could respond with errors and requests for interaction. The user would need to navigate to the linked page and confirm their consent there. It would be upon you, to correlate the interaction request from the MCP Server and the user confirmation on the web page. A JWT query param could be a good way to correlate these two interactions in a tamper-proof and stateless way.

@shlomiken Thanks for taking a look!

Resource server is one of the roles that an MCP server plays, but not the only role. This proposal enables the MCP server to take the role of OAuth Client for any downstream resource servers it needs to access.

Yeh , after thinking more - it make sense

although the spec say the MCP Client act as Oauth 2.1 client - which is confusing i think .

Another thing i'm not fully understand is if the auth loop is closed at the MCP server then how the client is being notified on that , and re-issue their tool request . also what in the protocol can be used as session (since we don't have cookies here)
so request 6, and 7 in the quick diagram i put together .

One more question to oauth guys - isn't that approach make DCR redundant ? a MCP server only knows a finite number of resource servers he will talk with , why do we need Dynamic registration then ?

Regarding confidential clients - my bad, i updated my comment , probably you saw it later. i then read that even if you use OS native secure storage , IDPs cannot rely on an app to do so , so all installed apps are public.

Another thing i'm not fully understand is if the auth loop is closed at the MCP server then how the client is being notified

This is the "Transactional" aspect I've been pushing for. I believe that this User Interaction capability would really benefit from a robust Server -> Client tracking / notification upon landing and not as a follow-on.

@shlomiken

although the spec say the MCP Client act as Oauth 2.1 client - which is confusing i think .

This is correct for the authorization between the MCP client and MCP server. The type of authorization we're talking about here is when an MCP server needs authorization to a downstream API. For example, a Personal Assistant MCP server needing authorization to Google's APIs for a particular user. It is a bit confusing, but the MCP server can play both the OAuth resource server and client roles. Remember, these are better considered roles that can be played instead of fixed capabilities.

Another thing i'm not fully understand is if the auth loop is closed at the MCP server then how the client is being notified on that , and re-issue their tool request .

We have added a section back into the spec for how the MCP client can monitor the progress of the interaction from the MCP server. We did this to leverage existing capabilities in the MCP spec. This can accomplish the arrow number 6 in your diagram.

As @ggoodman points out, there is appetite in the community for a better pattern when dealing with asynchronous operations. We don't want to introduce a new pattern for that in this PR, but are open to changes in the future.

also what in the protocol can be used as session (since we don't have cookies here)

The MCP server receives an access token from the client. Depending on the implementation, the server can leverage the subject identifier as a way to track which user to link the downstream credentials to. This can be used to deliver arrow number 7 in your diagram. Ultimately, this will be up to the exact implementation of the MCP server and its authorization server for how to do this.

One more question to oauth guys - isn't that approach make DCR redundant ? a MCP server only knows a finite number of resource servers he will talk with , why do we need Dynamic registration then ?

I think this question is confusing the roles again. DCR is required for MCP servers that will not necessarily know their clients ahead of time. Think my particular instance of Claude Desktop I have installed wanting to access your MCP server. The MCP server, however, may act as an OAuth client to the Google API. In that case, it's a different OAuth flow entirely and DCR may not be required.

On the UAInteraction object, I see the url field is specified with format: "uri". This means we have the option of supporting non-browser interactions. For example, a server could send a tel: URI to initiate a call, or perhaps a custom scheme like apple-pay:// to trigger a native payment. Is that intentional and OK? URL And URI are often used interchangeably but it might be useful to be explicit in the spec.

Hi @nbarbettini, given the Elicitation is now part of the MCP spec, I could imagine the following election request schema

"requestedSchema": {
  "type": "object",
  "properties": {
    "secureFlow": {
      "type": "string",
      "title": "Open Link To Provide Secrets",
      "description": "Start Secure ...."
      "default":"https://somehost/secure/flow"
      "format":"uri"
    },
  },
  "required": ["secureFlow"]
}

where do we stand with User Interaction ?

Hi @nbarbettini, given the Elicitation is now part of the MCP spec, I could imagine the following election request schema

"requestedSchema": {
  "type": "object",
  "properties": {
    "secureFlow": {
      "type": "string",
      "title": "Open Link To Provide Secrets",
      "description": "Start Secure ...."
      "default":"https://somehost/secure/flow"
      "format":"uri"
    },
  },
  "required": ["secureFlow"]
}

where do we stand with User Interaction ?

@adranwit
The MCP Elicitation draft spec states

Servers MUST NOT use elicitation to request sensitive information.

In your example, does "required": ["secureFlow"] qualify as sensitive information?

@nbarbettini instead of adding this functionality as a client capability, why not as a MCP Proxy Server capability?

Why change the target? B/c the MCP Proxy Server definition

An MCP server that connects MCP clients to third-party APIs, offering MCP features while delegating operations and acting as a single OAuth client to the third-party API server.

seems to more accurately describe the role of "client" you are describing.

Is there still interest in pursuing this proposal / addition? It seems to have stalled, curious why that is. Perhaps it is being discussed elsewhere or there is another proposal?

@dmiyamasu thanks for the feedback. In this scenario, elicitation could simply results in a URL being rendered or opened by the MCP host. At this stage, there's nothing inherently secure about that interaction—the MCP client is just triggering a link. Whatever happens after that (i.e., within the URL target) is entirely out of scope for the MCP protocol and the elicitation process itself.

So, even though "secureFlow" is a required field, it's just a URI. No sensitive data is being directly requested or transmitted via elicitation. The actual handling of secrets or sensitive input—if any—would happen within the hosted flow pointed to by the URL, which is beyond the control or visibility of the MCP client. In addition, I'd assume any of secure flow would generate URL that can be redeem only once.

Therefore, in my opinion this doesn't violate the draft spec’s guidance that “Servers MUST NOT use elicitation to request sensitive information.”

Hey folks! Not stalled. We're working through all the things in order to rework this on to of the most recently released version that includes elicitation. I hope to have something ready this week!

Edit: I, unfortunately, did not quite make it over the line this week. Will definitely be early next week! Thanks for your patience, folks!

Thanks for putting this proposal @nbarbettini
On reading through the discussion one of the problems it immediately solved for us was "Authorization" on tool calls.

After going through the draft and all the discussions I realised it will be so much cleaner if authorization was handled between the third party API and its AS and would like your review on the same, whether or not this will be a good design or has any holes in it.

For example: A user calls a tool "approve_pull_request" to approve any PR on a Github MCP server. This requires checking if the user is authorized to approve PRs in that particular git repo or not. Our very initial thought was to handle these checks when the MCP tool is called - on the MCP server or with a custom AS. But with this proposal I feel its simplified, as an MCP server can only do what the user has the permissions to do on Github. It removes any scope of privilege escalation or access misconfiguration (In the case where we were handling checks at tool calls)

@Xerenz Yes, you understood the proposal correctly! In cases like yours where an MCP server is calling a downstream API (such as GitHub) on behalf of the end-user, the best place to check the user's authorization is in the downstream API itself (or its authorization server). Otherwise, MCP servers must re-build a ton of authorization logic.

However, the MCP server may need to pass an authorization challenge back to the end-user ("click here to authorize access to GitHub"). Some MCP servers are nested within other MCP servers, so the "pass back" mechanism needs to be robust and something that can be programmatically forwarded to upstream servers. That's the foundational principle of this proposal.

Hey everyone! Thanks for all the great feedback here. To keep things clean we've created a new PR for the updated version of this proposal: #887
Comments and reviews are quite welcome. See ya there!