An MCP proxy server uses one static client ID with a third-party authorization server and lets MCP clients register dynamically. An attacker registers a client with its own redirect URI; the third party sees a consent cookie and skips consent. What mitigation is required?

The confused deputy attack arises when an MCP proxy uses a static client ID with a third-party authorization server, allows MCP clients to register dynamically, the third party sets a consent cookie after the first authorization, and the proxy does not implement per-client consent. An attacker registers a client with a malicious redirect URI and sends the user a crafted link; the third party sees the cookie, skips its consent screen, and the proxy sends the resulting MCP authorization code to the attacker. The security best practices say proxies must implement per-client consent: keep a registry of approved client IDs per user, check it before initiating the third-party flow, show an MCP-level consent page naming the client, scopes and redirect URI with CSRF and clickjacking protection, and validate redirect URIs by exact match. Passing the client's token through fails because token passthrough is forbidden and does nothing about the skipped consent. Longer-lived consent cookies fail by concept: the cookie bound to the static client ID is what enables the attack, so extending it widens the window. Accepting any redirect URI on the same domain fails because the guidance requires exact string matching, not patterns or wildcards. Exam caveat: the OAuth state value must be stored only after consent is approved and be single-use. Operational check: register a new client and confirm the proxy shows its own consent page before redirecting.