Field Journal

Authentication & Authorization / Protocol

Model Context Protocol Authorization

Model Context Protocol (MCP) authorization protects an MCP client's access to a remote MCP server over HTTP. The 2026-07-28 specification profiles OAuth, protected-resource metadata, authorization-server discovery, client registration, and resource indicators. Authorization itself is optional for an MCP implementation; where it is used over HTTP, the profile applies. It does not authorize local stdio transports, and it does not permit an MCP server to pass a client token through to an unrelated upstream API.

Transport determines whether the authorization profile applies

Discovery and authorization sequence

MCP authorization discovery: a client makes an unauthenticated call, obtains protected-resource metadata from the 401 WWW-Authenticate challenge, falling back to well-known URI probing, discovers and registers with an authorization server, sends the canonical resource URI in both the authorization and token requests, and presents the resource-bound token. A footer lists the three validations the client owns.

The header path is preferred and well-known probing is the fallback; the resource indicator binds both requests to the target MCP server

  1. The client calls the MCP server without a token and receives 401 Unauthorized.
  2. The client obtains OAuth Protected Resource Metadata. It must use the resource_metadata URL from the WWW-Authenticate header when one is present, and otherwise fall back to probing the well-known URIs — the MCP endpoint’s sub-path form first, then the root form. The server side must implement at least one of those two mechanisms; the client must support both.
  3. The metadata’s authorization_servers field names one or more authorization servers, and choosing between them is the client’s responsibility. Each is an independent OAuth authorization server: client identifiers and tokens are per authorization server and must not be assumed to work at another.
  4. The client retrieves authorization-server metadata, trying the OAuth 2.0 Authorization Server Metadata endpoint before OpenID Connect Discovery, with defined path-insertion rules for issuer URLs that carry a path. It must then check that the issuer inside the returned document matches the identifier used to build the URL, and reject the document if it does not. This is what stops a document fetched from an attacker’s well-known endpoint from claiming an honest issuer.
  5. The client registers by one of three mechanisms (below) and records the authorization server’s issuer before redirecting.
  6. The client sends the canonical MCP server URI in the resource parameter of both the authorization request and the token request, and must send it even if the authorization server ignores it.
  7. On the authorization response, the client validates the iss parameter against the issuer it recorded, using exact string comparison with no scheme, host, port, slash, or percent-encoding normalization. This applies to error responses too — on a mismatch the client must not act on or display the error.
  8. The authorization server issues an access token for that resource. The client presents it in Authorization: Bearer on every request; it is never placed in a query string.
  9. The MCP server validates that the token was issued for it as the audience, and rejects tokens issued for anything else. It must not accept or forward any other token.

The MCP specification profiles OAuth 2.1, which is still an Internet-Draft — the 2026-07-28 revision pins a specific draft revision rather than a finished RFC. Implement against the exact MCP revision and the draft it names rather than treating “2.1” as a finalized standard label.

Client registration choices

Clients that support all three should follow the specification’s priority order: pre-registered information if available, then Client ID Metadata Documents if the authorization server advertises client_id_metadata_document_supported, then Dynamic Client Registration if a registration_endpoint exists, and only then prompt the user.

Approach Fit Risk and operation
Pre-registration Managed enterprise clients and stable deployments. Strong administrative control; requires coordinated distribution and rotation of client metadata and credentials. Credentials are specific to one authorization server.
Client ID Metadata Document The default for the common case where client and server have no prior relationship. The client ID is an HTTPS URL resolving to a JSON document that must contain a matching client_id, a client_name, and redirect_uris. The authorization server fetches and validates it, which makes fetch-side URL and redirect restrictions and cache policy load-bearing. Client IDs are portable across authorization servers.
Dynamic Client Registration Deprecated. Retained only for backwards compatibility with authorization servers that do not support Client ID Metadata Documents. New implementations should not choose it. Where it is used, registration-endpoint abuse, redirect URI quality, and client lifecycle need explicit policy, and an OIDC authorization server may reject registrations whose application_type conflicts with a native-style redirect URI.

Authorization server binding. Pre-registered credentials, and any persisted from Dynamic Client Registration, must be stored against the issuing authorization server’s issuer identifier. If protected-resource metadata later names a different authorization server, the client must not reuse the old credentials — it re-registers, or surfaces an error rather than silently trying a mismatched pair. Client ID Metadata Documents avoid this problem, because the authorization server resolves the URL on demand.

Scope selection and step-up

The WWW-Authenticate challenge can carry a scope parameter naming what the current operation needs, and the client should treat those scopes as authoritative for that operation. When no scope is offered, the client falls back to the scopes_supported list in the protected-resource metadata.

At runtime an insufficiently scoped token produces 403 Forbidden with error="insufficient_scope" and the required scopes. The client re-authorizes with the union of what it previously requested and what the challenge now names, so a per-operation challenge does not silently drop permissions the client still needs. Scope accumulation is the client’s job; servers should emit all scopes an operation needs in one challenge rather than one at a time.

The reason to care is blast radius. A token granted every scope up front is a single credential whose theft reaches every tool, and revoking it disrupts everything at once.

Authorization is narrower than tool safety

An access token proves that the client holds the represented authorization to call the MCP server. It does not prove that a tool is safe, that a tool description is trustworthy, or that the user approved a destructive invocation. Treat tool metadata and tool output as untrusted content, enforce server-side authorization per tool and resource, and require explicit confirmation for consequential actions — MCP & Agentic Security covers that layer.

Two further boundaries worth keeping straight:

Security and lifecycle checklist

What I need to remember

MCP's HTTP authorization profile uses protected-resource discovery and OAuth resource indicators to obtain a token for exactly one MCP server. Prefer the WWW-Authenticate path and fall back to well-known probing, validate the issuer twice — in the metadata document and in the authorization response — key client credentials to the authorization server that issued them, prefer Client ID Metadata Documents now that dynamic registration is deprecated, reject token passthrough, and keep tool authorization and human approval separate from OAuth login.

Primary references