MCP Authorization

What it is

MCP authorization is the part of the Model Context Protocol that says how an AI client (an agent, IDE or chat app) gets permission to call a remote MCP server on a user's behalf. The answer is plain OAuth, profiled tightly: the MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client, and a separate authorization server issues tokens. The specification picks "a selected subset" of existing standards rather than inventing new ones.

That choice matters for practitioners. Securing MCP is mostly about running OAuth correctly, and the MCP authorization glossary entry gives the one-paragraph version. This page covers what the current revision requires and what it leaves to you.

Status (November 2026)

The current MCP protocol version is 2026-07-28, per the MCP versioning page read on 5 November 2026. Earlier revisions are 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05. MCP is hosted by the Linux Foundation's Agentic AI Foundation, to which Anthropic donated it in December 2025. "Stable" here means a released protocol revision, not an IETF or OpenID standard.

The revision depends on two moving IETF drafts. It cites OAuth 2.1 draft-13, while the draft has reached -17 (31 October 2026). It makes Client ID Metadata Documents the preferred registration method and cites revision -00, while the OAuth working-group draft is at -03 (2 November 2026, WG Document). Everything else it relies on is a published RFC.

Two authorization extensions are stable for 2026-07-28, in the ext-auth repository: OAuth Client Credentials (agents acting as themselves) and Enterprise-Managed Authorization (ID-JAG). The DPoP profile, SEP-1932, is open.

How it works

A concrete flow, a coding agent connecting to https://mcp.example.com/mcp for the first time:

1. Challenge. The client sends an MCP request without a token. The server answers 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read".
2. Resource metadata (RFC 9728). The client fetches that document, which names one or more authorization servers. Servers must implement RFC 9728; if the header is missing, clients probe the well-known path for the MCP endpoint and then the root.
3. Authorization server metadata. The client tries RFC 8414 and OpenID Connect discovery URLs in a set order, and must reject a document whose issuer does not match the URL it constructed.
4. Registration. Clients use this priority: a pre-registered client ID if one exists; a Client ID Metadata Document if the server sets client_id_metadata_document_supported: true; Dynamic Client Registration (RFC 7591) as a deprecated fallback; finally, asking the user. With CIMD, the client_id is an HTTPS URL with a path (for example https://app.example.com/oauth/client-metadata.json) and the server fetches it to check client_name and redirect_uris.
5. Authorization request. The client opens the browser with an authorization code request carrying a PKCE challenge, the scope from the challenge, and resource=https://mcp.example.com/mcp. RFC 8707 resource indicators are mandatory in both the authorization and the token request, and the client must send them even if the server ignores them.
6. Issuer check. On the redirect, the client compares the iss parameter with the issuer it recorded (RFC 9207) before sending the code anywhere, which blocks mix-up attacks.
7. Token and calls. The client redeems the code with the PKCE verifier and resource, then sends Authorization: Bearer on every HTTP request.
8. Step-up. If a later tool call needs more, the server returns 403 with error="insufficient_scope" and the full set of required scopes. The client re-authorizes with the union of old and new scopes.

The server-side rules are short and strict: validate every token, accept only tokens issued for this server as audience, and never pass a received token through to an upstream API. If the MCP server calls another API, it is an OAuth client there and gets its own token.

Enterprise-managed authorization

The per-server consent flow above works for individuals and breaks down in companies, where an employee might connect an agent to dozens of MCP servers and each grant is invisible to IT. The Enterprise-Managed Authorization extension replaces it with ID-JAG: the client signs the user in through the corporate IdP, exchanges the ID token at the IdP for an ID-JAG whose audience is the MCP server's authorization server, and redeems that for an access token. The IdP evaluates admin policy at the exchange, so the enterprise decides which clients may reach which MCP servers.

What it solves for AI agents and SaaS

For SaaS vendors exposing an MCP server, the profile gives a known shape for security review: an OAuth resource server with audience-bound tokens, discoverable metadata and per-operation scopes. For agent builders, it removes the worst early practices: API keys pasted into config files, tokens valid at any server, and proxies that forward a user's token upstream. SWI's Agent Identity Standards Map 2026 scores token audience binding and client registration at 5 of 5, largely because MCP requires them.

What it leaves open: tokens are bearer tokens held by a process that reads untrusted input, so a prompt-injected agent can be steered into misusing a valid token. Scopes are coarse, so per-call limits need a policy engine such as AuthZEN. Revocation mid-task needs short lifetimes and Shared Signals.

Adoption signals (verified)

• Official MCP TypeScript SDK. The client auth module checks client_id_metadata_document_supported, and the auth extensions module implements the ID-JAG exchange, checked 5 November 2026.
• Okta Agent SSO, generally available since 24 August 2026, describes connecting Cross App Access agents to enterprise applications "and MCP servers".

How to implement or evaluate

• Building an MCP server: publish RFC 9728 metadata, return precise scope in challenges, validate aud against your canonical URI, reject everything else, and keep offline_access out of your advertised scopes.
• Running the authorization server: support CIMD with a domain trust policy, PKCE with S256, the iss response parameter, short access-token lifetimes, and refresh-token rotation for public clients. Consider DPoP where clients support it.
• Deploying in an enterprise: prefer pre-registration or Enterprise-Managed Authorization over open registration, and inventory which agents hold refresh tokens for which servers.
• Reviewing a vendor: ask which MCP revision they implement, whether they still rely on DCR, and whether their server forwards tokens upstream.

Pitfalls

• Token passthrough. Forbidden by the spec and still common in quick proxies.
• Trusting the resource parameter alone. If the authorization server ignores RFC 8707, the token may lack a narrow audience. Servers must still check it.
• Localhost redirect URIs in CIMD. The security considerations warn about localhost redirect risks; restrict which domains' metadata documents you accept.

Related

ID-JAG and Cross App Access, OAuth 2.1, OAuth Transaction Tokens, AuthZEN, the securing AI agent identities guide and the AI agent identity tools ranking. Glossary: Client ID Metadata Document, protected resource metadata, dynamic client registration, agent registry, credential brokering.