Flow 1
Detect mix-up
- 1
Client starts a flow at AS B, storing expected issuer from B's metadata.
- 2
Attacker causes the user-agent to deliver AS A's response to the client.
- 3
Client sees iss=A ≠ expected B and aborts. No token request is made.
IETF · March 2022
RFC 9207
K. Meyer zu Selhausen, D. Fett
Agents that talk to many authorization servers (SaaS tools, multiple MCP servers) are mix-up-prone. This is a small check that prevents a large class of token theft.
At a glance
Actors
01
In mix-up attacks the client is tricked into sending an authorization response from AS A to a flow it started with AS B. Agents that talk to many authorization servers (SaaS tools, multiple MCP servers) are mix-up-prone. RFC 9207 returns iss in the authorization response so the client can detect that.
MCP 2026-07-28 requires iss validation. Always set expected issuer from metadata, not from the response.
02
The client compares iss to the AS it intended (from its own state + metadata). Simple string comparison. The response is otherwise unauthenticated until this check (and PKCE) succeed.
03
AS includes iss in the authorization response (including errors). Client compares with the intended issuer. RFC 9207, March 2022.
04
Flow 1
Client starts a flow at AS B, storing expected issuer from B's metadata.
Attacker causes the user-agent to deliver AS A's response to the client.
Client sees iss=A ≠ expected B and aborts. No token request is made.
05
Authenticates which AS produced the authorization response. Small check, large class of token theft.
06
9700's mix-up mitigation.
Source of the expected issuer.
MUST validate iss.
AS shall return iss per 9207.
07
iss is a detector, not a discovery mechanism. Expected issuer comes from your state.
08
RFC 9207, March 2022, K. Meyer zu Selhausen, D. Fett. Stable. https://www.rfc-editor.org/rfc/rfc9207.html
MCP 2026-07-28 requires iss validation. Always set expected issuer from metadata, not from the response.