What the MCP authorization spec actually requires

Model Context Protocol (MCP) is the protocol an agent uses to talk to tool servers. As of mid-2025, MCP has a formal authorization specification. It's worth reading the full thing if you're shipping MCP integrations. This is a quick map of what it says, what it leaves alone, and where the load-bearing decisions are.

What MCP authorization is

MCP defines an OAuth 2.1-flavored authorization flow at the transport layer. The protocol's role is narrow: tell the client how to discover the authorization server, how to register, how to obtain a token, and how to present it on requests. It defers nearly everything else to the OAuth standards it's built on.

The headline pieces:

• Authorization is optional. STDIO transports are explicitly told not to follow the spec — they should pick up credentials from the environment. HTTP transports SHOULD follow it.
• Standards reused: OAuth 2.1 (draft), RFC 8414 (authorization server metadata), RFC 7591 (dynamic client registration), RFC 9728 (protected resource metadata), and importantly RFC 8707 (resource indicators).
• Discovery is two-stage. The client first fetches the protected-resource metadata from the MCP server (so it knows which authorization server to talk to), then fetches that authorization server's own metadata.
• Dynamic client registration is encouraged. Servers SHOULD support RFC 7591 so clients don't need pre-issued credentials per server.
• Tokens are audience-bound. The spec requires the resource parameter on token requests (RFC 8707), and the resulting token is bound to that specific MCP server.

What MCP authorization isn't

The spec is explicit about its boundaries. It does not tell you:

• What scopes mean. The spec uses OAuth scopes but leaves the scope vocabulary to the server. "files.read", "issues.create", "deploy.staging" — those are your problem.
• How to attribute requests to a specific user behind the agent. The token represents the client. If you need delegation semantics (this agent acting on behalf of Alice for this task), you need to layer that on yourself.
• How to enforce policy beyond "the token is valid." Token validation is a binary gate. Whether this particular request with these particular arguments should be allowed is up to your server.
• How to audit. No log format, no decision record, no chain of custody. You design the audit story.

The two most important things the spec gets right

Token audience binding. The spec's security considerations call out the confused-deputy risk specifically: an MCP server that accepts tokens issued for other MCP servers is the entire OAuth confused-deputy problem reincarnated. RFC 8707 resource indicators force the token's audience to be explicit, and the spec requires server-side audience validation. This is a real engineering win — without it, an attacker who compromises any one MCP server gets a credential they could replay against others.

Dynamic client registration. Without RFC 7591, every new MCP server requires out-of-band client-credential setup. With it, an MCP client can self-register. This is what makes the ecosystem composable. It's also what makes it dangerous if your authorization server's registration endpoint is permissive — you'll want a registration policy that doesn't auto-trust unknown clients.

What's left for you

For any production deployment, you'll need to add:

• A user delegation model. OAuth gives you "this app on behalf of this user, at this moment." MCP doesn't say anything about whether the same flow applies between an agent acting on a user's behalf and an MCP server. Most teams reach for token exchange (RFC 8693) to encode the chain.
• A policy layer. Token validation tells you the request is from an authorized client. It doesn't tell you whether deleteUser({id: 42}) is one you should run.
• An audit trail. The spec is silent here. Whatever you log, log it structured and log it signed — a flat text log is not a chain of custody.

The MCP spec is good at what it tries to do: standardize the transport-level authorization handshake so clients and servers can interoperate. Treat it as the floor. The interesting decisions — policy, delegation, audit — are above it.