Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Context

As described in the MCP spec, when there is a 3rd party auth provider, there are four actors:

1. The end-user
2. The MCP client — which could be any website or app on the Internet
3. The MCP server — which is an OAuth provider to the MCP client
4. The upstream provider (GitHub) — the MCP server is the OAuth client of this

MCP clients obtain client IDs without user interaction — dynamic client registration (link). Most OAuth providers (ex: GitHub) do not support dynamic client registration. This means that for a given end user, there exists a many-to-one relationship between MCP clients and a single upstream authorization grant. An end user who logs into Claude on desktop, and then on mobile, has multiple MCP client sessions, sharing a single authorization with the upstream OAuth provider.

Problem

As described here, consider the following example (link), where GitHub is the upstream OAuth provider to the MCP server.

A bad actor can:

1. Know the hostname of the MCP server, ex: https://mymcp.example
2. Dynamically register a client to the MCP server
3. Send end users a URL like this: https://mymcp.example/authorize?client_id=<ID>&redirect_uri=https://evil.example
4. This redirects the end user through the 3rd party OAuth flow (GitHub), which calls back to the /callback URL, where the GitHub token is stored, and then the end user is redirected to the provided redirect_uri, which is provided the token that the MCP server itself has generated (not the upstream GitHub token)

So long as the bad actor can convince the end user to click the URL, this allows the bad actor access to the token that the MCP server issued, allowing it to call MCP tools, etc. (but not direct access to the upstream provider).

The core problem is that there is no opportunity for the end user to consent to grant access. In this example, they are sent to the GitHub authorization URL (link), but because the end user has already authorized the MCP server (remember that the MCP server here is acting as the OAuth client) — GitHub does not present a consent dialog to the end user. We believe strongly that GitHub and other OAuth providers should present a consent dialog every time that an end user is sent through authorization, but many today do not.

What should end users see?

Ideally the end user would first be presented with a consent dialog:

 “<Client name> is requesting to be able to use <MCP server name>”
 [Don’t Allow] [Allow]

Then, only once the end user consents, they would be sent to the authorization flow of the upstream OAuth provider (GitHub).

This is necessary because — even if the 3rd party OAuth provider (GitHub) did always show a consent dialog, it would today show something like:

“<MCP server name> is requesting the following access to your account at <GitHub>”
[Don’t Allow] [Allow]

…because it is the MCP server that is the OAuth client. Because the MCP client isn’t directly requesting access, the consent page can’t clearly show the identity of the MCP client that will ultimately gain access to make requests to the MCP server. The end user has no way of seeing this, it’s not clear to them what client they are granting access to, in the case of a link from a bad actor.

And because most OAuth providers do not themselves support dynamic client registration, there is no way for the MCP server to dynamically create a new OAuth client ID with GitHub, and maintain a 1:1 mapping between MCP Client ID and an OAuth client ID used with the upstream provider (GitHub).

This consent dialog would allow the MCP server to explain why they are sending the end user through a 3rd party authorization.

How could the MCP spec be improved to solve this?

It seems like there are two paths:

1. Require 3rd-party OAuth Providers to always present a consent screen AND support dynamic client registration — and require MCP servers to dynamically generate OAuth client IDs when acting as MCP clients
2. Require MCP servers to implement their own upfront consent dialog, as described above, and require that MCP servers must enforce that this upfront consent dialog cannot be bypassed.

(1) is the ideal end state. But much more challenging as it requires existing OAuth providers to change in ways that they may not be willing or able to, at least easily. (2) is more friction for end users, and more complexity for MCP servers to get right.

Functionally, (2) would mean the MCP server must do something like store a cookie during the initial consent screen and tie the state value sent upstream to that cookie, so when redirected back, the MCP server can (and must) verify that the user actually did see and consent.

(2) effectively makes MCP auth look like this to the end user:

1. Allow permission to ?
2. Sign into <3rd party OAuth provider> (if not already)
3. Allow to access on your <3rd party OAuth provider> account?

This maps most literally to what is happening, it is the most clearly explicit. But it means that every MCP server must implement and render some dialog for (1). It’s not clear that there can be a safe and trusted way for (1) to be rendered more directly by the MCP client, since the MCP client is untrusted.

Assuming Option 2 — what would MCP server implementation do?

When the MCP client sends the end user to the /authorize endpoint, the MCP server will need to:

1. Check if the end user has already consented to the client ID (MCP Client) being allowed access
2. If so, send them to the 3rd party auth
3. If not, render a consent dialog, and handle user input

MCP servers probably need helpers for a default consent dialog page that developers can simply plug in and use — and then can modify as-needed. Ex: a helper that redirects to the consent URL, and a helper that renders a page with the consent dialog. And somewhere within these, a cookie gets set automatically. Point is — there's a bit more here for MCP servers and tooling around them to handle on behalf of developers, in order to make this truly easy and pluggable.

What should OAuth providers support, in order to make this simpler?

As noted above, OAuth providers should:

1. Always present a consent screen to the user that is send to the authorization URL
2. Support dynamic client registration

It seems like the MCP spec could make this explicit, even if it does not make it mandatory?