Confused deputy, token passthrough, SSRF

Remote MCP servers often call other APIs on the user's behalf. Three classic mistakes:

Confused deputy. A deputy is a program acting with more authority than its caller. Imagine your MCP server is an OAuth proxy to a third-party API and uses one fixed client ID with that API. If the user already consented to that client ID once, a malicious MCP client can trick the flow into skipping consent and receive a code for the user's account. Mitigation: the MCP server must obtain its own per-client user consent before forwarding to the third party, and strictly validate redirect URIs and state values.

Token passthrough. Accepting a token from the client and forwarding it unchanged to a downstream API (or accepting tokens issued for some other service) breaks audience checks, audit trails and rate limits, and lets stolen tokens be replayed. The spec forbids it: accept only tokens issued for your server, and get separate tokens for downstream calls (for example via token exchange).

SSRF (server-side request forgery). During discovery, a client fetches URLs supplied by servers (metadata, authorization endpoints). A malicious server can point those at internal addresses such as cloud metadata services or localhost. Clients and servers that fetch URLs should require HTTPS, block private and link-local ranges, and not follow redirects blindly.

Also in the security guide: scope minimization (start with minimal scopes, step up when needed), session/state hijacking (never trust unverified handles for identity; bind state to the authenticated user), and mix-up attacks (check the iss value so one authorization server can't impersonate another).