Why is authorization the hard part of MCP?

Connecting a model to your real tools means connecting it to your real data and actions, so access control matters. MCP’s authorization model is built on OAuth 2.1, and it assigns each participant a specific role: the MCP server is a resource server that validates incoming tokens and enforces what they permit; a separate authorization server issues those tokens after the user authenticates; and the MCP client acts as the OAuth client, requesting tokens on the user’s behalf.^[1] A mid-2025 revision of the spec tightened this further, requiring that an MCP server act only as a resource server and never issue or validate tokens on its own — token issuance has to live in a dedicated authorization server, not be improvised by whoever wrote the tool.^[1]

Role separation closes off the obvious mistakes, but four risks remain even when the spec is followed correctly:

• Token passthrough, where a server forwards a client’s token straight to some upstream API instead of validating it itself. This is the specific mechanism behind a confused-deputy attack: a downstream service ends up trusting a token that was never meant for it, and something with legitimate access gets tricked into using that access on someone else’s behalf.^[1]
• Token interception, which is why OAuth 2.1 mandates PKCE (a proof tied to the original request) for the authorization code exchange — without it, a stolen authorization code is as good as a stolen token.^[1]
• Weak scope enforcement, especially over long-lived streaming connections, where a token that has outlived its intended permissions keeps working because nothing rechecks it mid-session.^[1]
• Poisoned tool descriptions, where an instruction hidden in a tool’s own metadata — text the model reads as trusted setup, not as untrusted input — gets obeyed the same way a prompt injection would. This one is not an OAuth problem at all; it lives entirely in how the model treats tool text, which is why the prompt injection page is the deeper read.

Contained, these are ordinary access-control engineering. Ignored, they turn “the model can read my calendar” into “the model can be talked into reading anyone’s.” The rules and guardrails page covers the broader pattern of constraining what an agent is allowed to do once it is authorized to do anything at all.