MCP Authorization: Under the Current Spec, First Answer 'Who Are You'

Introduction

MCP (Model Context Protocol) is the standard wiring between AI applications and external tools: an MCP host (such as Claude Code, Claude Desktop, or VS Code) creates one client per MCP server, and servers expose three primitives — tools, resources, prompts. This piece examines its authorization model under the official current MCP authorization specification (version 2026-07-28; verified on 2026-10-06 that /specification/latest redirects here). (Product analysis current as of 2026-10-06.)[1]

[1] [2]

Authorization remains optional

The current specification: Authorization is OPTIONAL. Implementations using HTTP SHOULD follow this specification; local servers using STDIO SHOULD NOT follow this OAuth flow, and instead retrieve credentials from the environment. Note this is SHOULD NOT, not technically cannot — whether local is safe depends on process isolation and credential custody, which the specification leaves to implementers.[2]

[2]

Three roles

The current specification sets out a 'Roles' section naming three parties: the protected MCP server is the OAuth 2.1 resource server; the MCP client is the OAuth 2.1 client, making protected resource requests on behalf of a resource owner; the authorization server interacts with the user when necessary and issues access tokens, and may be hosted with the resource server or as a separate entity — its implementation details are out of scope for this specification. 'Who issues tokens' and 'who receives tokens' are formally separated.[2]

[2]

Resource and audience binding

The current specification requires clients to implement Resource Indicators per RFC 8707: the resource parameter MUST appear in both authorization and token requests, identifying the canonical URI of the MCP server the token is for; the server, acting as resource server, MUST verify that access tokens were issued specifically for it as the intended audience, accepting only tokens issued by its own authorization server for its own resources, and MUST NOT accept or transit any other tokens. Tokens are bound to resources: one token, one place.[2]

[2]

DCR deprecated

In the current specification, Dynamic Client Registration (DCR) is deprecated and retained only for backwards compatibility; authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents. Before initiating the authorization flow, clients MUST obtain a client ID through one of three mechanisms — Client ID Metadata Documents, pre-registration, or DCR — in the priority order defined by the specification.[2]

[2]

Scope challenges and step-up

The current specification details handling for insufficient permissions: servers MAY include a scope parameter in the 401 WWW-Authenticate header guiding the required permissions; when a token is rejected for insufficient scope, the server SHOULD respond 403 with insufficient_scope — note this is the insufficient-scope case; invalid or expired tokens still receive 401. The client re-authorizes with a larger scope set via the step-up flow and retries.[2]

Two different kinds of 'human' need distinguishing: step-up re-authorization runs the OAuth authorization flow, which clients acting on behalf of a user SHOULD attempt per the specification — and that flow itself may require user interaction; the authorization protocol permits and in some cases requires interactive authorization. But that is not the same as 'mandatory human approval for every tool call'. The former is a mechanism inside the authorization protocol; the latter is host-layer call policy. They are not the same thing.[2]

[2]

The 401 handshake

When authorization is required and the client has not yet proven it, the server responds HTTP 401 and the client then initiates the OAuth 2.1 flow; tokens travel in the Authorization header, never in the URI query string (an OAuth 2.1 Section 5 requirement cited by the current specification). Clients validate any returned iss against the recorded issuer; they must reject a missing iss only when the authorization server advertises support for it (RFC 9207).[2]

[2]

The enterprise answer

The enterprise extension (independently versioned) turns the organization's IdP into the authoritative decision-maker: employees sign in once, and the IdP decides which MCP servers they can access under organizational policy; per the extension documentation, in deployments that implement and support the extension, revocation happens once at the IdP layer, taking effect immediately across all clients. No hands-on testing of implementations was done; not all MCP deployments are guaranteed to behave this way. Per-person authorization is reasonable for consumers; in enterprises it creates friction and gaps.[3]

[3]

Commentary

1. The protocol standardizes only the handshake, not the policy. The 'Roles' section explicitly places authorization server implementation outside the specification's scope — MCP does not even decide 'who issues tokens' for you. This is an honest design: when evaluating a deployment, look at the authorization server's side, not the wire itself.

2. DCR's deprecation shows the protocol converging. The shift from 'dynamically register everything' to 'declare identity metadata first' moves trust from runtime negotiation to registration-time declaration. Convenience yields to auditability — the typical trajectory of a maturing protocol.

3. 'On whose behalf' remains the origin. The current specification keeps the distinction in its step-up section: 'clients acting on behalf of a user' versus 'client_credentials clients' follow different flows [2]. Acting impersonating a user versus acting as the application itself imply completely different audit and revocation logic — ask this first in selection, then ask about scopes.

4. The authorization protocol is not per-action approval. Scope challenges and step-up are permission mechanisms inside the protocol, and step-up may involve user interaction; but 'mandatory human approval for every tool call' is a different matter, belonging to host-layer policy. When designing an agent publishing pipeline, the protocol layer ('may this token be used') and the policy layer ('is this call approved') must be separated — just as drafting, review, and release signing must never be the same hands.

5. Four questions for practitioners (current spec). Who is the authorization server (co-hosted with the resource server or independent)? Is resource/audience binding actually enforced? What is the server's scope challenge strategy (how is 403 used)? Which of the three client registration mechanisms is used? If you cannot answer, do not connect production data yet.

[2]

What cannot yet be asserted

How completely hosts and clients implement the current specification (not hands-on tested);

The real-world deprecation progress of DCR;

The actual security posture of specific MCP servers (per their own documentation and audits).