How does authorization work for MCP servers?

This entry describes the Model Context Protocol (MCP) authorization specification as of revision 2026-07-28, which the MCP versioning page listed as the current revision on 13 October 2026. Later revisions may change these requirements.

Key findings #

Evidence #

What to do #

For engineers #

For an MCP server over HTTP, publish Protected Resource Metadata, answer unauthenticated requests with a 401 that points to it, and check the audience of every token. Put the scopes an operation needs in the WWW-Authenticate challenge, all at once. If the server calls other APIs, get its own token for each of them. The token exchange entry shows one way to do that.

For an MCP client, implement both discovery mechanisms, PKCE with S256, the resource parameter, and the issuer check. Never put tokens in the query string.

An MCP server on the STDIO transport is outside this specification, which says such servers should take credentials from the environment. Keep those credentials short-lived and task-scoped, as my AppSec essay recommends for coding agents.

For product and UX #

Start with the minimal scopes and ask for more only when an operation needs them. The specification warns that misconfigured scopes may require frequent user interaction, and that challenging one scope at a time forces several authorization round-trips for one operation.

How it works #

The specification defines 3 roles. The MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client acting for a resource owner, and the authorization server issues the tokens. Authorization is optional for MCP implementations. Implementations on HTTP-based transports should conform to the specification, and STDIO implementations should not.

A first connection follows these steps:

1. The client sends an MCP request without a token. The server answers with HTTP 401 and a WWW-Authenticate header that carries the resource_metadata URL from RFC 9728 and, as the specification recommends, the required scope.
2. The client fetches the Protected Resource Metadata and picks an authorization server from it. It then reads that server’s metadata through OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery. Clients must support both, and if the metadata doesn’t list code_challenge_methods_supported, the client must refuse to proceed.
3. The client gets a client ID. It uses pre-registered client information if it has some, then Client ID Metadata Documents if the authorization server supports them. Dynamic Client Registration is deprecated and kept only as a fallback for backwards compatibility.
4. The client starts the authorization code flow with PKCE, the resource parameter and the selected scopes, and records the expected issuer. When the response comes back, it validates the iss parameter (RFC 9207) before it redeems the code.
5. The client redeems the code with the code_verifier and the resource parameter, then sends the access token in the Authorization: Bearer header on every request.

When a token lacks a scope at runtime, the server answers with 403 and error="insufficient_scope". The client then runs a step-up flow with the union of its previous scopes and the new ones.

Revision 2026-07-28 doesn’t cover token exchange in its core authorization pages. Optional authorization extensions live in a separate repository. In the Agentic Identity Broker, which Magnus Jungsbluth and I built, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693, so the provider token never reaches the agent. I describe that design in the retrospective, and we presented it in our AGNTCon + MCPCon talk.

Related #

• Should an agent use a robot account or delegated access?
• How should people grant and revoke an agent’s access?
• Agentic Identity Broker