MCP OAuth rules ban shared client IDs across servers

MCP's OAuth authorization flow closes off a mixup attack, where a rogue authorization server impersonates a trusted one, per Duende's July 30 breakdown of six hardening proposals.

The attack works when a client juggles multiple authorization servers and can't tell which one it's actually talking to. SEP-2468 fixes that by requiring the iss parameter on every authorization response, per RFC 9207. A client can then confirm which server actually issued the response before trusting it.

Two more proposals tighten the edges. SEP-837 has authorization server operators validate redirect URIs against a declared application_type. SEP-2352 requires a separate set of credentials for every authorization server a client connects to, instead of one shared identity.

That last one has teeth. An MCP client that reuses one client_id across every authorization server is out of spec under this release candidate, per Duende's breakdown. The SEP ties that rule to a concrete failure mode, not a theoretical one.

The proposals also point toward CIMD as a further step, though Duende's write-up doesn't spell out what that migration involves.

MCP clients built before this spec update probably chose the easy, insecure path: one client_id shared across every authorization server. That pattern is already out of spec in the release candidate Duende reviewed.

Duende posted its review July 30, as the OAuth hardening proposals move through MCP's release candidate process.