Will - The `iss` response parameter approach is also far easier to deploy than the multiple redirect URL mitigation approach. Deployment can be done in a forward-compatible way without manual coordination between existing OAuth ASs and OAuth clients.
For a non-MCP flavored example - there are many OAuth client "aggregator" implementations today. These are services that manage access and refresh tokens for a wide number of external APIs. Think of companies like Zapier in the no-code space, Nango in the product integration space, or various Token Vault services in the AI space. These aggregators often manage many client identities to facilitate integrations with multiple separate OAuth ASs. If we require these aggregators to move to a separate redirect URL per AS instead, every pre-existing client registration containing the old redirect URL will need to be updated. These updates must be performed manually by the aggregator's customers. An aggregator cannot tell an AS that "cust_client_1234" is now using a new redirect URL - only the owner of "cust_client_1234" (the aggregator's customer) can do that. In comparison, a rollout of the `iss` response parameter does not require the client registration to be updated. As soon as an AS starts to support the `iss` response, all clients of that AS can begin enforcement. All (Zapier <-> Google) interactions can be secured at once. *I am supportive of making this response parameter mandatory in 2.1*. Best, Max On Thu, Dec 18, 2025 at 1:08 PM Will Bartlett <wibartle= [email protected]> wrote: > Hi folks, > Following Aaron's suggestion, I want to surface OAuth 2.1 Github issue 223 > for discussion on this mailing list - > https://github.com/oauth-wg/oauth-v2-1/issues/233. I am hopeful that we > can close on this issue by mail. > > *Summary:* OAuth 2.1 incorporates RFC 9207's issuer response parameter > optionally. I believe OAuth 2.1 should make this parameter mandatory. > > *Rationale:* > > - MCP needs this to mitigate the mix-up attack. > - Enabling clients to mitigate the mix-up attack requires a very small > amount of work from servers - returning a constant response value (iss). > - We (OAuth WG) should strive for a simpler world for non-auth experts > where non-auth specifications (like MCP) can just reference OAuth 2.1 and > be secure. It should not be necessary for non-auth experts to reference > OAuth 2.1 and also read many OAuth 2 extensions and evaluate which of those > extensions are needed for security. > > > The status quo (optional) makes implementing OAuth 2.1 slightly easier for > OAuth providers, at the cost of requiring more complex security analysis > from specifications that reference OAuth 2.1 (like MCP) and clients that > implement OAuth 2.1 (like MCP clients). Given that the implementation > burden on OAuth providers is very small, I believe that mandating this > response parameter is the right tradeoff. There will undoubtably be a small > flurry of activity when OAuth 2.1 is finalized where implementations > advertise their compliance. We should take advantage of that opportunity to > mitigate the mix-up attack once and for all. > > *Attack in detail: *See > https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1721#issuecomment-3555689564 > . > > Thanks, > Will Bartlett > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
