The lack of issuer being required just points to the exact security flaw when it isn't being required. I don't think anyone needs to be reminded of that. The point to suggest that issuer be required in OAuth2.1 is something I am also in favor of.
On Fri, Dec 19, 2025 at 10:19 PM Max Gerber <[email protected]> wrote: > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
