Episode 198 - GluuFederation/identerati-office-hours GitHub Wiki

Title: Mix-Up Attacks in MCP: Multi-Issuer Confusion and Mitigations

Channels

Description

MCP deployments increasingly involve multiple authorization servers / identity providers across tools, registries, gateways, and enterprise environments. That flexibility introduces a classic but under-discussed class of failures: mix up attacks. A mix-up attack is where a client or intermediary confuses which issuer/authorization server it’s interacting with and misroutes sign-in artifacts, such as tokens, to the wrong party, potentially a malicious one. Emily uses her pets to build a threat model for mix-up in MCP-style topologies (client↔server↔auth server). No animals were harmed in the creation of this model!

Homework

Takeaways

  • ⚡ MCP attacks are possible when one trusted OAuth Authorization Server (Cat) manipulates an OAuth client to return a code for a different Authorization Server (Guinea Pigs). With MCP servers interacting with multiple Authorization Servers, this hard to detect attack will become more common.

  • ⚡ PKCE doesn't stop mix-up attacks. PKCE proves the client relationship, but it doesn't verify that the response came from the authorization server the client intended to use.

  • ⚡ Issuer validation is the critical mitigation. Clients must remember which authorization server they started with and verify that the same issuer completes the flow.

  • ⚡ Not all OAuth Authorization Server JWTs contain an iss claim--right Auth0? But RFC 9068 "JWT Access Tokens" defines iss as REQUIRED, and RFC 9207 "OAuth 2.0 Authorization Server Issuer Identification", adds the issuer as a "response parameter", similar to the state param.

  • ⚡ Vibe coding probably won't help, unless the developer specifies the exact OAuth RFCs and profiles to use.

Livestream Archive