An attacker triggers a URL-mode elicitation that starts a third-party OAuth flow, then sends the link to a victim, who completes the authorization. The server binds the resulting third-party tokens to the attacker's account. What must the server do to prevent this?
Select an answer to reveal the explanation.
Short Explanation
This is the old 'sign here for me' con. The attacker starts the flow, the victim finishes it, and the server pins the victim's account to the attacker. You stop it by checking at your connect page that the person finishing is the same person who started.
Full Explanation
The elicitation specification describes this phishing attack directly: a URL-mode elicitation returns a URL an attacker can forward, a victim completes the third-party authorization believing it is their own, and the server binds the victim's third-party tokens to the attacker's identity, resulting in account takeover. To prevent it, the server MUST ensure the user who started the elicitation is the same user who completes the authorization flow, and MUST verify the identity of whoever opens the URL before accepting information. A common pattern sends the user to the server's own connect URL, which compares the authenticated subject from the MCP authorization server with the browser session's subject before redirecting to the third-party authorization endpoint. The client's accept response only records consent to open the link and says nothing about who later completes the flow in a browser. Form mode SHOULD NOT carry clickable URLs and would not change who finishes the flow. Putting an access token in the URL is forbidden, since URLs must not carry credentials or grant pre-authenticated access. Exam caveat: the identity check must resist an attacker who modifies the elicitation URL. Operational check: start an elicitation as one test user, open the link in a browser signed in as another, and confirm the server refuses to continue.