Wiki · Concept · Last reviewed June 25, 2026

MCP Authorization

MCP authorization is the Model Context Protocol profile for allowing HTTP-based MCP clients to make requests to restricted MCP servers on behalf of resource owners.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Authorization, OAuth, AI Agents, Token Boundaries, Governance

Definition

MCP authorization is the authorization profile in the Model Context Protocol for restricted MCP servers reached over HTTP-based transports. The 2025-11-25 specification describes authorization as optional for MCP implementations, but says HTTP-based transports should conform to the MCP authorization specification when authorization is supported. It also says stdio implementations should not follow that HTTP authorization profile and should instead retrieve credentials from the environment.

The narrowness matters. MCP authorization is not a general proof that a tool call is safe, that the user understood every downstream effect, or that an AI agent has a complete legal mandate. It is a protocol-level way to bind MCP client requests, protected MCP servers, authorization servers, scopes, and access tokens into a checkable flow.

Scope and Roles

In the MCP profile, a protected MCP server acts as an OAuth resource server. An MCP client acts as an OAuth client, making protected resource requests on behalf of a resource owner. The authorization server interacts with the user when needed and issues access tokens for use at the MCP server. The specification is based on a selected subset of OAuth-family standards, including OAuth 2.1 draft work, OAuth Authorization Server Metadata, Dynamic Client Registration, OAuth Protected Resource Metadata, and OAuth Client ID Metadata Documents.

This placement separates three jobs that are often blurred in agent interfaces: the MCP server exposes tools or context, the authorization server issues tokens, and the client presents or invokes the connected capability. A governed deployment should name all three.

Discovery

MCP servers that support this authorization flow must implement OAuth Protected Resource Metadata. MCP clients must use protected resource metadata for authorization server discovery, and the protected resource metadata must include an authorization_servers field with at least one authorization server. MCP clients must support discovery through a WWW-Authenticate header carrying a resource_metadata URL and through well-known protected-resource metadata locations.

MCP authorization servers must provide OAuth Authorization Server Metadata or OpenID Connect Discovery. MCP clients must support both mechanisms so they can discover token endpoints, authorization endpoints, supported capabilities, and PKCE support.

Resource Indicators

The MCP authorization specification requires MCP clients to implement OAuth Resource Indicators. The client must include the resource parameter in both authorization requests and token requests. That parameter must identify the MCP server for which the token is being requested, using the canonical URI of the MCP server.

RFC 8707 explains the reason for this pattern: the authorization server may need to know the protected resource where a token will be used so it can construct a token valid for the intended recipient. For MCP, this becomes a core anti-confusion control. A token for one MCP server should not silently become authority at another server or a downstream API.

Tokens and Scopes

MCP clients must send access tokens in the HTTP Authorization header on every HTTP request to the MCP server, even inside the same logical session. Tokens must not be placed in URI query strings. MCP servers must validate that access tokens were issued specifically for them as the intended audience, and invalid or expired tokens must receive an HTTP 401 response.

For scopes, MCP clients should request the least privilege needed for the intended operation. The initial flow should use the scope value from the WWW-Authenticate challenge if present; otherwise it can use scopes_supported from protected resource metadata. At runtime, insufficient scope can be signaled with HTTP 403 and a WWW-Authenticate header that names the required scopes and resource metadata. Clients acting for a user should attempt step-up authorization rather than silently broadening authority.

Governance Requirements

An MCP authorization record should preserve the MCP server canonical URI, protected resource metadata URL, authorization server issuer, client identity method, requested scopes, granted scopes, resource parameter, token audience, redirect URI, PKCE status, step-up events, denial events, token expiry policy, and any downstream service calls triggered by the MCP server.

Most importantly, the record should say whether the MCP server called an upstream API with its own separately issued token. MCP security guidance treats token passthrough as an anti-pattern: a server must not accept a client token not issued for that server and pass it to a downstream API.

Failure Modes

Consent laundering. A broad connector approval becomes evidence for actions the user never saw in concrete form.

Audience drift. A token intended for one resource is accepted by another resource because audience validation is weak or absent.

Token passthrough. An MCP server forwards a client token downstream, breaking audience boundaries and confusing audit trails.

Scope inflation. A client requests every advertised scope because it lacks domain knowledge, then treats the resulting grant as routine.

Source Discipline

Claims about MCP-specific authorization requirements should cite the versioned MCP authorization page. Claims about protected resource metadata should cite RFC 9728 or the site's protected-resource metadata entry. Claims about the resource parameter should cite RFC 8707. Claims about token passthrough should cite MCP security guidance or the MCP authorization section on access token privilege restriction.

Spiralist Reading

MCP authorization is where delegated machine action tries to become accountable authority. The protocol asks a concrete question: for which server, under which scopes, through which issuer, did this client receive power?

The Spiralist warning is that authorization screens can become ritual. A clean OAuth flow can still hide a vague operational mandate. Authorization only becomes governance when it leaves a receipt that a human can inspect later.

Open Questions

Sources

Return to Wiki