How the Model Context Protocol Handles Authorization

The Model Context Protocol (MCP) connects AI clients to external servers that expose tools and data. When those servers hold restricted resources, the protocol needs a way to prove that a request is allowed. The MCP authorization specification at https://modelcontextprotocol.io/specification/draft/basic/authorization defines how that works for HTTP-based transports, building on a selected subset of established OAuth standards.

Optional, and Transport-Specific

Authorization is described as OPTIONAL for MCP implementations. The behavior depends on the transport in use. Implementations using an HTTP-based transport SHOULD conform to the specification. Implementations using an STDIO transport SHOULD NOT follow it and instead retrieve credentials from the environment. Implementations using alternative transports MUST follow established security best practices for their protocol.

Rather than inventing a new scheme, the spec layers on existing work. It references OAuth 2.1, OAuth 2.0 Bearer Token Usage (RFC 6750), Authorization Server Metadata (RFC 8414), Protected Resource Metadata (RFC 9728), Resource Indicators for OAuth 2.0 (RFC 8707), and others. The stated goal is to implement a subset of these features to balance security and interoperability with simplicity.

The Three Roles

The spec assigns each participant an OAuth role. A protected MCP server acts as an OAuth 2.1 resource server, accepting and responding to requests that carry access tokens. An MCP client acts as an OAuth 2.1 client, making those requests on behalf of a resource owner. A separate authorization server interacts with the user when necessary and issues the access tokens.

Importantly, the implementation details of the authorization server are left outside the scope of the spec. It may be hosted alongside the resource server or run as a separate entity. This keeps the protocol focused on the boundary between client and server rather than dictating how identity is managed internally.

Discovery and the Authorization Flow

Because clients do not know in advance which authorization server a given MCP server trusts, the spec defines a discovery process. An MCP server MUST implement OAuth 2.0 Protected Resource Metadata, and clients MUST use that metadata to locate the authorization server.

The flow starts when a client sends a request without a token. The server replies with an HTTP 401 and a WWW-Authenticate header pointing to its protected resource metadata. The client reads that metadata, finds the authorization server, retrieves its metadata, obtains a client ID, and then runs an OAuth authorization handshake using PKCE. The client also includes a resource parameter, required by RFC 8707, that names the specific MCP server the token is meant for. After the user authorizes, the client receives an access token and retries the original MCP request with it.

Token Validation and Scopes

Tokens travel in the standard Authorization: Bearer header, and the spec states that access tokens MUST NOT be placed in the URI query string. Authorization MUST be included on every HTTP request from client to server.

On the receiving side, the MCP server, in its role as a resource server, MUST validate that an access token was issued specifically for it as the intended audience. It MUST only accept tokens valid for its own resources and MUST NOT accept or transit any other tokens. Invalid or expired tokens MUST receive an HTTP 401 response.

The spec also leans on scopes to apply least privilege. Servers can advertise required scopes in the WWW-Authenticate challenge, and when a token lacks a needed permission at runtime the server SHOULD return HTTP 403 with error="insufficient_scope" and the scopes required. Clients then perform a step-up authorization flow, requesting a token with the expanded scope set rather than over-requesting permissions up front. This audience binding and scope handling is what separates MCP authorization from simply passing credentials through to a backend.