An MCP client records the expected issuer before redirecting the user to an authorization server. The authorization response comes back with an iss value that differs from the recorded issuer. What must the client do?
Select an answer to reveal the explanation.
Short Explanation
You wrote down who you were expecting before you left, and someone else answered the door. That's a mix-up attack in progress, so you stop right there and never hand the code to anyone's token endpoint. Don't fall for the idea that PKCE saves you here — it doesn't.
Full Explanation
The authorization specification requires clients to record the issuer from the selected authorization server's validated metadata before redirecting, alongside the PKCE verifier and state. On receiving the authorization response the client MUST apply RFC 9207 validation before transmitting the code to any token endpoint: a present iss is compared to the recorded issuer by simple string comparison, and a mismatch means the response is rejected. This defends against mix-up attacks, in which an attacker-controlled authorization server tries to get a code from an honest server sent to its own token endpoint. PKCE does not stop this, because the client would hand the code_verifier to the attacker's token endpoint along with the code. Overwriting the recorded issuer with the received value defeats the entire purpose of recording it. The resource parameter binds a token to an MCP server's audience, but it offers no protection when the attacker intercepts the exchange before any honest server is involved. Exam caveat: the mismatch rule applies to error responses too, and on mismatch the client must not act on or display error, error_description or error_uri. Operational check: test the client with a response whose iss differs by one character and confirm no token request is sent.