Diving Into the MCP Authorization Specification

Editor's note: This post was originally published on April 11, 2025, and was written to address the draft specification that went live in June 2025. The MCP authorization spec has since been revised several times, most significantly on July 28, 2026.

We've updated this post to reflect those changes, marked open questions that have since been answered, and noted where the spec now requires what we previously recommended. For a full breakdown of the 2026 revision, see our analysis of the latest spec.

The Model Context Protocol (MCP) is an emerging open standard that allows AI systems (like LLMs) to interact with external tools and data in a standardized way​. Early MCP deployments ran the MCP server and client together in a local and controlled environment, meaning there was no need for complex authorization.

As organizations begin to deploy MCP servers remotely, the need to better secure sensitive data and operations has become urgent. To answer this need, the MCP specification introduced a new authorization component based on OAuth 2.1 with the goal of leveraging battle-tested standards to protect MCP endpoints. 

This guide covers the core concepts of MCP authorization and explains how those elements are sometimes misapplied or misunderstood. 

We’ll cover:

• Why OAuth-style authorization matters for MCP

• Requirements MCP places on implementers 

• Current challenges being discussed in the community 

• Insights into open questions about MCP

The evolution of MCP and authentication

Originally, MCP clients could talk to MCP servers directly through stdio (often on the same machine), so authentication was minimal. As the MCP ecosystem evolved, the need arose to call MCP servers across the network (e.g., Streamable HTTP), such as by third-party applications on behalf of users. 

For example, a user might run an MCP client application that needs to access their data on a remote MCP server in a data center. The user (resource owner) must grant the client access to the server, ideally without handing out passwords or API keys. This is exactly the problem OAuth solves—delegated authorization.

Because modern organizations have existing identity providers (IdPs) or OAuth2 authorization servers, the maintainers of MCP chose to piggyback on OAuth 2.1 rather than creating a new scheme. This means an MCP server can trust tokens issued via an OAuth flow, and MCP clients can obtain those tokens by redirecting users to an authorization server. 

Familiar OAuth roles can now enter the MCP picture: the MCP server acts as the resource server, the OAuth IdP is the authorization server, and the MCP client is the OAuth client requesting access on behalf of the user. However, as we’ll see, the current MCP specification leaves the final implementation of the concepts up to interpretation. 

Fortunately, the June 2025 revision was a major upgrade of the specification, addressing earlier concerns (especially for enterprise) by clearly separating the MCP server (resource server) from the authorization server role. Every revision since, especially the July 2026 release, has built on that separation rather than changing it.

Need a refresher on OAuth? Read our beginner-friendly guide.

MCP authorization requirements at a glance

The MCP Authorization Specification establishes a framework based on OAuth 2.1 to secure interactions between MCP clients and servers.

Note that previously the specification called for fallback default endpoints at /authorize, /token, and /register. The June 2025 revision removed this mechanism in favor of mandatory RFC 9728 (Protected Resource Metadata).

What the July 2026 revision adds

The July 28, 2026 revision layers six requirements onto this framework, all of them formalizing behavior that mature authorization servers already exhibit:

• Clients validate the issuer identifier (iss) on authorization responses per RFC 9207, mitigating mix-up attacks across MCP's many-server deployment pattern (SEP-2468)

• Clients declare their OpenID Connect (OIDC) application_type (web or native) during registration, so authorization servers stop misclassifying desktop clients (SEP-837)

• Registered credentials are bound to the issuing authorization server; if a resource migrates to a new one, clients register again (SEP-2352)

• Refresh tokens are requested through the standard offline_access scope (SEP-2207)

• During scope step-up, the client computes the union of existing and newly required scopes (SEP-2350)

• /.well-known/oauth-authorization-server discovery is clarified (SEP-2351)

We cover each auth SEP in more detail in our analysis of the 2026 revision.

The revision also promotes Enterprise-Managed Authorization (EMA) to an official extension. EMA lets an enterprise identity provider (IdP) govern which MCP clients can reach which MCP servers on behalf of which users, using the Identity Assertion JWT Authorization Grant (ID-JAG) from Cross-App Access (XAA). The IdP issues a signed assertion under admin policy, and the MCP server's authorization server validates it and mints its own scoped tokens, with no per-user consent screens.

See our ID-JAG/XAA explainer to learn more.

Why these components matter

OAuth 2.1: Provides a standardized security framework with mandatory PKCE to protect against authorization code interception attacks. Since most MCP clients are public (like CLI tools or apps), PKCE is always required.

Dynamic Client Registration: DCR allows MCP clients to obtain credentials (a client ID and possibly secrets) at runtime rather than requiring manual pre-registration. While MCP’s maintainers encourage this, not all IdPs support it, and it often requires initial access tokens or admin privileges. Thus, many enterprises may bypass this by pre-registering trusted clients.

Authorization Server Metadata: ASM allows MCP clients to discover authentication endpoints automatically. Without this discovery mechanism, developers must hardcode endpoint locations, complicating interoperability. When ASM is implemented, an MCP client discovers the authorization server location via the Protected Resource Metadata document, then queries the authorization server's .well-known/oauth-authorization-server endpoint. The authorization server metadata is hosted by the IdP, not the MCP server.

Protected Resource Metadata: MCP servers MUST implement RFC 9728, which describes OAuth 2.0 Protected Resource Metadata (PRM). When authorization is required, servers return HTTP 401 with a WWW-Authenticate header containing the resource_metadata URL pointing to the PRM document. This document includes the authorization_servers field indicating where clients should obtain tokens. It can define multiple authorization servers, but the responsibility for selecting which one to use lies with the MCP client.

Implementation challenges and community discussions

The MCP specification’s approach to authorization has sparked active community debate. The June 2025 revision successfully addressed the biggest concern by clearly separating the MCP server (resource server) from the authorization server. The MCP server now simply validates tokens issued by external authorization servers (e.g., enterprise IdPs). However, implementation challenges remain.

Key technical challenges

• SDK integration issues: SDKs and reference implementations often assume MCP servers are also the authorization server, making third-party integration trickier.

• Token lifecycle management: Spec mandates complex token mapping and tracking when using third-party authorization, which significantly increases the implementation burden.

Previously, there were issues with connection protocol limitations, but the July 2026 revision has mostly resolved them. Before, Server-Sent Events (SSE) endpoints lacked clear conventions for handling insufficient scopes or token expiry during active connections. Stateless transport replaced this method, removing long-lived streams entirely.

Best practices for MCP authorization implementation

With so much developer feedback, several MCP implementation best practices are emerging. These both aim to simplify deployment while accounting for potential vulnerabilities in the current specification.

Separate authorization servers from resource servers

The June 2025 revision now mandates this separation. MCP servers act as OAuth 2.1 resource servers only, validating tokens issued by an external, dedicated authorization server. This aligns with enterprise architectures where security is centralized. The MCP server’s job is to validate tokens and enforce RBAC/permissions internally, but not to manage user logins or token issuance.

When we originally published this blog in April 2025, we also advised implementers to keep MCP servers stateless (or at least not to store OAuth state). As of the July 28, 2026 spec revision, the spec applies the same principle one layer down, removing protocol sessions from the transport entirely. These are different mechanisms, but they follow the some principle: keep the durable state with the authorization server, not the MCP server

Prevent token passthrough

When MCP servers need to call upstream APIs, they must act as OAuth clients to those services and obtain separate tokens. Never pass through the token received from the MCP client, as this creates confused deputy vulnerabilities. This is a scenario where downstream services may incorrectly trust tokens not intended for them. The June 2025 spec explicitly prohibits MCP servers from passing through tokens to upstream APIs.

Point MCP clients to an external authorization server

If you have an existing IdP (Identity Provider), configure your MCP server to advertise that issuer’s metadata rather than hosting its own. This can be done by populating the .well-known/oauth-authorization-server response or responding with a WWW-Authenticate: Bearer … header that contains the IdP’s discovery/documentation URL. This helps the MCP client to know exactly where to perform the OAuth exchange securely.

Implement function-level scopes for better AX

MCP authorization should optimize for Agent Experience (AX)—minimizing unnecessary friction for agents, and not bombarding humans with scope-related prompts. MCP tool calls may not map one-to-one with APIs, so scopes should be validated at the tool or function level. On top of scope validation for all routes at the middleware level, the request object can be parsed to determine the tool call or resource involved, checking for specific scopes (e.g., a view scope for viewing a document).

While recent revisions to the MCP authorization spec resolve the most pressing issues, enterprises face additional deployment challenges beyond the most glaring obstacles. These include multi-tenancy complexities, auditing capabilities, and single sign-on (SSO), the last of which the EMA extension now addresses. For a complete analysis of enterprise MCP deployment challenges, see 5 Enterprise Challenges in Deploying Remote MCP Servers.

Questions and recommendations

The following questions are drawn from past and current outstanding issues, some of which the MCP spec has resolved, and others that still stand. Understanding the MCP authorization spec's past and current state can provide much-needed insight into its future.

How clients establish trust (resolved)

When it comes to DCR, knowing that the information you get about a client is trustworthy becomes paramount for MCP server owners. This question has since been answered: OAuth Client ID Metadata Documents (CIMD), originally proposed in SEP-991, is now the specification's recommended registration approach, letting servers establish trust through domain-hosted metadata, with DCR remaining the fallback for clients that can't host metadata.

Hardening that DCR fallback still remains a crucial consideration for those who need it. See our Tips to Harden OAuth Dynamic Client Registration in MCP Servers to learn more.

Scope discovery and AX

How should an MCP client know what scopes to request during the OAuth flow? The specification doesn’t define scopes—implementors must decide. A fixed scope like access_mcp may suffice in some cases, and the ASM can list scopes_supported, though without indicating which scopes are needed for a specific action. Scopes not lining up with agent intent can lead to AX friction. The July 2026 revision addresses part of this by standardizing scope step-up: the server signals what it needs, and the client requests the union of its existing and newly required scopes.

DCR security

A key future consideration is how secure and standardized Dynamic Client Registration should be. The current OAuth specification allows for flexibility, but this can open the door to client impersonation or unverified registrations. This becomes particularly important for federated environments or public tools, where the authorization server needs to assert trust before issuing credentials.

Production implementations require additional hardening beyond base RFC 7591. Anonymous DCR creates legitimate security concerns, especially for enterprise. These risks include difficulty monitoring, auditing, and mitigating potential attacks. Organizations need verification flows, IP reputation checks, and risk-based controls to safely implement DCR at scale.

For detailed guidance on implementing production-ready and scalable DCR, see our guide on Tips to Harden OAuth Dynamic Client Registration in MCP Servers.

Handling 403 over SSE connections (resolved)

Previous versions of this post asked how servers should signal insufficient scopes or token expiry mid-stream, since SSE offered no standard way to handle errors after the initial 200 OK. The July 2026 revision resolves this by removing long-lived streams: transport is stateless, authorization errors are returned per-request, and servers may only issue requests to the client while actively processing one of the client's requests. Scope enforcement now happens where it always belonged, at the individual request.

Universal JWT validation via JWKs

Ideally, an MCP server accepts JWTs directly from a trusted IdP, verifies them via JWKs, and authorizes based on included claims or scopes—without issuing its own token. This requires:

• IdP-issued JWTs to include necessary claims.

• MCP server to validate signatures via jwks_uri.

This stateless approach avoids the need for token mapping and call-backs to the IdP. The specification has since moved toward this model rather than away from it: stateless, per-request validation is now the protocol's posture, and the July 2026 issuer-validation requirements assume exactly this kind of trust relationship between the resource server and its issuer.

Exploring MCP authorization approaches

As MCP matures from a local developer tool into a remote-first protocol for secure, cross-system AI integration, its authorization model must evolve accordingly. The June 2025 revision represents a significant step forward in aligning MCP with enterprise needs.

That refinement has been steady: SEP-991 (Client ID Metadata Documents) graduated from proposal to the spec's recommended registration approach, and the July 2026 revision brought stateless transport, six new authorization requirements, and official extensions like EMA.

The good news is that the broader OAuth ecosystem provides a wealth of battle-tested solutions. By strictly treating MCP servers as resource servers, reusing external identity providers, and embracing modern standards, teams can reduce implementation complexity and avoid reinventing the wheel.

However, while the specification provides the foundation, production deployment requires going beyond the basics.

How Descope simplifies MCP authorization

Implementing the latest MCP authorization specification for production environments takes expertise, knowledge, and patience. Typical implementations mean navigating complex OAuth flows, spending cycles to implement CIMD or harden your DCR against novel threats, and managing tokens in niche ways. Challenges like these can (understandably) overwhelm even the most experienced enterprise identity teams.

Descope provides MCP SDKs that help organizations add OAuth 2.1 authorization, PKCE, DCR/CIMD, and other authorization capabilities required by the MCP specification in three lines of code. For organizations building internal MCP servers, the Agentic Identity Hub provides control, traceability, and policy-based governance. 

Whether you're building your first MCP server from scratch or scaling a project to production, Descope eliminates auth complexity so you can focus on building the next big AI experience. Explore Descope's AI-focused demos or start building now with a Free Forever account.

FAQs about the MCP authorization specification