Hi all,
I’d like to put in my two cents, drawing on our research into practical mix-up attacks in the wild [1]-[3].
For MCP, I’m supportive of making RFC9207 (
iss parameter in auth response) mandatory. Since the MCP spec mandates RFC8414 AS Metadata in the first place, it provides a trusted, verifiable source for the issuer value. Also, as Will pointed out on MCP Github issue, with CIMD (Client ID Metadata Document) now adopted by MCP as a DCR alternative, it would be hard to apply the distinct redirect_uri defense, as the hosted CIMD document is typically static and includes a fixed redirect_uris array.I have only one minor concern:
> RFC9207 Section 4: Clients ... MUST NOT allow multiple authorization servers to use the same issuer identifier. In particular, when authorization server details can be manually configured in the client, the client MUST ensure that the accepted
iss values are unique for each authorization server.There are legit use cases where two benign MCP servers with the same AS/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 AS (but two AS 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.
For a future-proof OAuth 2.1, I’m hesitant about whether we should mandate
iss in the broader OAuth world outside MCP.The
iss defense works best when paired with RFC8414 OAuth AS Metadata, but AS Metadata is not REQUIRED by OAuth 2.1. Without it, it’d be hard to know what to return as iss value (for an AS) and/or hard to verify the authenticity of iss value (for the OAuth Client). It is documented that,> RFC9207 Section 2.4: If OAuth metadata is not used, clients MUST use deployment-specific ways (for example, a static configuration) to decide if the returned
iss value is the expected value in the current flow … > RFC9207 Section 4: When OAuth metadata is not used, the client can use, for example, a statically configured expected
iss value for each configured authorization server.This means without RFC8414, the exact value of
iss which an AS returned in authorization response, as well as its validation, hinges on its actual configuration/coordination with a particular client. This raises implementation costs, complicates conformance testing, and may also open room for issuer spoofing. Conversely, when RFC8414 is used, the expected value and authenticity of iss is anchored in the HTTPS-hosted metadata, where its "issuer" claim equates the server origin.For protecting existing OAuth 2.0-compliant ecosystems, my take is enforcing
iss is less practical.OAuth 2.0 will be around for a long time. If we wish to fix mix-up at early stage across all OAuth ecosystems, it should be noted that RFC9207 needs explicit opt-in, whereas distinct redirect_uri defense allows ASs and Clients only compliant with RFC6749 to be easily secured, as the latter defense does not involve protocol-level changes.
Outside MCP and a few niche ecosystems such as FAPI, RFC8414 OAuth AS Metadata adoption remains limited. This contrasts with the widespread deployment of OIDC openid-configuration by major IdPs. Likewise, today we also see limited support of RFC9207 across industry, both on AS and OAuth Client side.
Max mentioned "OAuth client aggregator implementations", including no-code/integration platforms and Token Vaults in Agentic AI. We have been investigating these ecosystems [1]-[2], and felt like the
iss parameter defense (RFC9207) would often be less practical than distinct redirect_uri:In these implementations, with each OAuth client supporting hundreds or thousands of pre-built and custom integrations, we may expect a long tail and cannot expect that the ASs would just supply the iss parameter. Each AS is protected individually only if they opt-in, and those who don’t remain unprotected.
On the other hand, distinct redirect_uri is more practical:
- For new deployments, there’s no extra burden. Mandating distinct redirect_uri by design provides the same protection for ALL ASs integrated at one platform/token vault.
- For existing deployments, it indeed requires ASs to update their redirect_uri in client registration, but this could be done with a transition period, after which non-updated ASs are blocked. We have worked with multiple vendors, such as Microsoft Power Platform (CVE-2023-36019), Amazon Bedrock AgentCore, and Arcade.dev to go through the process, with manageable efforts from customers/developers. (P.S. we believe a variant defense that uses distinct redirect_uri per AS instance, rather than per AS/issuer, may be even more practical for these implementations, given legit use cases where a client has multiple integrations with the same AS/issuer)
Overall, I think the cost of updating client registration is lower than adopting RFC9207 at scale. I understand AS adding a new parameter in authorization response itself is simple, but it is more than that:
- If the
iss is sourced from RFC8414, then both Client and ASs need to support RFC8414 for interoperability; Currently, most, if not all of these platforms/vaults rely on manually configured AS information in a platform-specific configuration, rather than conveyed through AS metadata (unlike MCP). - If the
iss does not rely on RFC8414, then the platform/vault’s OAuth client should generate aniss value for each AS, and the AS shall return that client-specificiss, rather than a constant, universal value, which takes additional efforts.
So my take is that regardless of whether we call it a secure-OAuth-2.0 or OAuth 2.1, if our goal is to protect existing OAuth implementations, especially for ALL OAuth2.0-compliant ASs, then I think distinct redirect_uri still has its value.
And certain OAuth use cases/profiles can definitely make
iss mandatory, such as FAPI (already), CIMD, MCP, etc.References:
Some of our work on mix-up attack analysis (referred to as Cross-app OAuth Account Takeover, COAT in our context)
[1] Low-code/No-code Integration Platforms: BlackHat USA 2024, OAuth Security Workshop 2025, USENIX Security 2025.
[2] Token Vaults in Agentic AI: BlackHat USA 2025 (Cross-agent COAT).
[3] IETF Interim Meeting, IETF Draft.
Thanks,
Kaixuan Luo
PhD Candidate
The Chinese University of Hong Kong (CUHK)
From: Warren Parad <[email protected]>
Date: Saturday, December 20, 2025 at 06:15
To: Max Gerber <[email protected]>
Cc: Will Bartlett <[email protected]>, [email protected] <[email protected]>
Subject: [OAUTH-WG] Re: OAuth 2.1 - make mix-up mitigation mandatory
Date: Saturday, December 20, 2025 at 06:15
To: Max Gerber <[email protected]>
Cc: Will Bartlett <[email protected]>, [email protected] <[email protected]>
Subject: [OAUTH-WG] Re: OAuth 2.1 - make mix-up mitigation mandatory
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
