Trust and Authorization in MCP
OAuth 2.1, the resource-server model, RFC 8707, and the threats the protocol cannot solve for you.
The security axis of MCP: how authorization works on the HTTP transport with OAuth 2.1, the server-as-resource-server model and RFC 8707 resource indicators, the later OIDC discovery and incremental-consent refinements, and the three threat classes, token passthrough, confused deputy, and prompt injection via tool output, with the guard for each.
A hotel key card is issued by the front desk, opens only your room, and stops working at checkout. It never reveals your name to the door, and losing it does not hand anyone your identity. MCP authorization gives a tool exactly that kind of key: a scoped, expiring token from an authorization server, so the tool can act on your behalf without ever seeing your actual password.
This is part of a series on MCP. Once a server lives on the network, the friendly local-subprocess story from the transports piece is over, and you have to answer a hard question: who is allowed to call this server, and with whose permission. As the ecosystem has moved toward remote, multi-tenant servers, this has become the most actively developed part of the protocol, so it is worth understanding the model even where a library implements the details.
Authorization: a token bound to its server
MCP's authorization framework is built on OAuth 2.1, and it applies to the HTTP transport. Local stdio servers do not use it; there, credentials are handled through the environment the process runs in.
The model treats an MCP server as an OAuth resource server, and the flow is designed to stop one specific, nasty attack.
A client calls the server without a token; the server responds with protected-resource metadata that says where to get authorized. The client goes to that authorization server and gets a token, and crucially it binds the token to the specific MCP server it intends to call, using a resource indicator from RFC 8707. Then it calls the server again with that bound token. Because the token names its intended audience, a malicious or compromised server cannot pocket a token meant for it and replay that token against a different, more sensitive server. The 2025-06-18 revision made this binding a requirement, precisely because token confusion is where these systems get breached.
The 2025-11-25 revision built on that foundation with the details real deployments need: OpenID Connect discovery so clients can find the authorization server the standard way, incremental consent so a server can ask for more scopes only when it actually needs them rather than demanding everything up front, and client-id metadata documents so a client can identify itself without heavyweight registration. The direction is clear: make MCP authorization look like the boring, well-trodden OAuth that enterprises already know how to run.
Step through the whole flow, from the first unauthorized call to the token-carrying one:
The threats the protocol cannot solve for you
Authorization handles who may call. It does not handle everything, and the honest part of any MCP security discussion is naming what is still your job. Three threat classes matter.
- Token passthrough. A malicious server replays a token meant for someone else. This is the one the resource-indicator binding above is built to stop: a stolen token names its target, so it is useless anywhere else.
- Confused deputy. A server with legitimate privilege is tricked into using it on an attacker's behalf. The guard is not cryptographic; it is architectural. The host is where the human approves actions, servers are kept isolated and narrowly scoped, and consent is explicit rather than assumed.
- Prompt injection via tool output. A server returns content, and that content carries hidden instructions that the model reads and obeys. This is the hardest one, because the protocol genuinely cannot solve it for you. The only real defense is to treat everything a server returns as untrusted input, the same way a web app treats everything a user submits.
The spec ships and keeps updating a dedicated security best-practices page for exactly these reasons. The existence of that page is the tell: people hit these problems in production, and the protocol authors decided the failure modes needed to be written down rather than left to each implementer to rediscover.
The honest summary
A protocol makes integration easier; it does not make it safe by default. MCP gives you a real, and by now quite mature, authorization model, and it binds tokens so they cannot wander. It does not, and cannot, stop a model from being talked into something by content a server fed it. If you expose anything that touches real money, real data, or real actions, the auth flow is the easy half; treating tool output as hostile, keeping servers least-privileged, and putting the human in the approval path is the half that actually keeps you safe.
The last piece steps back from the mechanics to the story: How MCP Grew, from launch to standard, and where it is going.
