Make RFC 9207 issuer validation (OAuth mixup attack prevention) mandatory

[will-bartlett]

The "OAuth Mixup Attack" is described in RFC 9207. Briefly, an OAuth client which connects to multiple OAuth provider (e.g. indicated by multiple MCP Servers) can become confused about which response comes from which OAuth provider, and thereby send an access token from one OAuth provider to another. RFC 9207 mitigates this attack by introducing an issuer ("iss") response parameter alongside OAuth responses to enable clients to prevent such mixups. OAuth 2.1 incorporates RFC 9207 as optional.

Ask: make the OAuth mixup mitigation mandatory in the MCP Specification.

Rationale: Most MCP clients will permit connecting to multiple MCP servers, with multiple OAuth providers. Popular in-market MCP clients make no attempt to require MCP servers to use a single OAuth provider. The use of multiple OAuth providers is uncommon in the wider OAuth ecosystem (which perhaps justifies the optional support in OAuth 2.1). However, the use of multiple OAuth providers is extremely common in the MCP subset of the OAuth ecosystem. This MCP, should make mitigating attacks against OAuth clients that use multiple OAuth providers mandatory.

[dend]

@aaronpk thoughts here?

I am assuming that this also depends on the authorization server supporting iss - do we have any of those?

[simonrussell]

However, the use of multiple OAuth providers is extremely common in the MCP subset of the OAuth ecosystem.

Is it? (You mean for a single resource?) Genuinely curious here.

[will-bartlett]

However, the use of multiple OAuth providers is extremely common in the MCP subset of the OAuth ecosystem.

Is it? (You mean for a single resource?) Genuinely curious here.

Same resource not required. Let's say you have two email accounts with two companies, each company operates an MCP server for their email, and an IDP. The client uses OAuth Client ID Metadata, so the id of the client is the same across both IDPs.

Pre-attack, legitimate user adds first email.

• client launches browser with IDP=IDP1, client=C, resource/scope=Email1, redirecturi=os-package-id
• user signs into IDP1
• user grants C access to Email1 in visual prompt on IDP1
• IDP1 returns authorization code to C
• C redeems authorization code with IDP1

And then second email the same way, with 1 replaced by 2.

Attack:

• user comes back to C after a period of disuse and or password change. IDP2 has been compromised, but the user does not know.
• IDP2 refresh token fails, so C shows the user that reauthentication is required with IDP2
• client launches browser with IDP=IDP2, client=C, resource/scope=Email2, redirecturi=os-package-id
• Compromised IDP2 redirects to IDP=IDP1, client=C, resource/scope=Email1, redirecturi=os-package-id
• user sees a login prompt for IDP1 and signs in
• user sees a prompt from IDP1 "Can C access Email1"
• user says yes
• IDP1 returns authorization code to C
• C redeems authorization code with IDP2

Now IDP2 is reading Email1.

This attack all hinges on the user granting C access to Email1 on Idp1 as part of an authentication flow for Email2 on Idp2. But that's not too hard to imagine - that's a lot of context to keep straight, particularly for a user who is fundamentally ok with C having access to Email1.

The "iss" response parameter cuts this attack off just prior to the final step. C sees that the authorization code came from IDP1, but realizes it was it was in the middle of an IDP2 flow, and so aborts before redeeming the IDP1 authorization code with IDP2.

There are other ways to mitigate this attack - the issuer is also present in the OpenID Connect id_token, and a client can use a different redirect uri per IDP instead of using the same one for all. But MCP currently supports pure OAuth and Client ID Metadata makes per-IDP redirect URIs impossible (and it's just unwieldy in the first place). So RFC 9207 seems the easiest. And it's what OAuth 2.1 does.

[will-bartlett]

And PKCE and DPoP don't help, because the client sends all the parameters to IDP2. IDP2 can just send them unmodified to IDP1, as long as it advertises the same capability set.

[will-bartlett]

The MCP client might also just not tell the user the context. An MCP client might just say "Some of your MCP servers require reauthentication" and then pop the browser. User can't notice they are being asked to sign into IDP1 on an Email2 flow if the client doesn't tell the user it's an Email2 flow

[simonrussell]

Yeah okay I was going to ask for an attack scenario -- I did some digging but couldn't find a great one; that helps.

• is CIMD (or otherwise same client ID) a requirement for this attack?
• is it necessary for the authentication to have succeeded, or can this happen on the first attempt? (Ignore whether it would be weird to the user, more just from a technical point of view)

If the answer is no to either then it might be good to strip it back to a minimal attack scenario, as there's quite a lot to think through.

I'm certainly happy to add iss to our implementation, it seems like a no-brainer. I've no idea how universal support for this is though, so can't really comment on whether it's good or bad to require it from a compatibility point-of-view.

[will-bartlett]

is CIMD (or otherwise same client ID) a requirement for this attack?

Having a publicly known client id is the requirement for the attack. That will be true for confidential clients, and public clients that are CIMD or pre-registered but probably not DCR (depending on whether DCR is implemented to assign a client id to the instance or product).

is it necessary for the authentication to have succeeded, or can this happen on the first attempt? (Ignore whether it would be weird to the user, more just from a technical point of view)

It can happen on the first attempt.

Maybe I'm in the wrong forum and should be chatting with the OAuth 2.1 folks about making iss mandatory instead. Then MCP will just get it by reference. Let me open an issue over there.

[EmLauber]

Note this mixup issue was discussed in the Auth IG 12/3/25 meeting. @pcarleton are you on point for next steps?

[KevinLuo2000]

I'm pasting part of my discussion on IETF OAuth WG mailing list:
https://mailarchive.ietf.org/arch/msg/oauth/9q_j2KKlkD96WchfIfXshJLqxUM/

While I'm supportive of making RFC9207 mandatory in MCP, there's one concern:

RFC9207 Section 4:
Clients ... MUST NOT allow multiple authorization servers to use the same issuer identifier.

There are legit use cases where two benign MCP servers using the same Authorization Server/IdP connect to one MCP client (e.g., two MCP servers using Google IdP, or an official vs. custom Dropbox MCP Server). Technically, such two MCP servers should (still) be considered as using one Authorization Server (but two Authorization Server instances), therefore not violating the normative text above.

However, I fear that some MCP clients may interpret the text differently, blocking a second MCP server simply because the issuer matches an existing one.

This may require a special call-out in the MCP spec for clarification.

[will-bartlett]

Fwiw, I think the text in RFC9207 is ok. But I don't think a callout in the MCP spec hurts anything either.

[EmLauber]

This issue has been adopted into a new WG focused on Mix Up Attack Prevention. We will be discussing this issue and other topics related to the mix up attack in the upcoming meetings.