MCP Authentication & OAuth 2.1: Authorization Flows, Token Management, and Enterprise Security Patterns

Authentication is the hardest problem in the MCP ecosystem. It’s the area that has evolved the most since the protocol launched in late 2024, the area that drew the sharpest community criticism, and the area where real-world vulnerabilities caused the most damage. If you’re deploying MCP servers beyond your local machine, you need to understand auth deeply.

This guide covers the full MCP authentication and authorization landscape as of August 2026, including the 2026-07-28 specification revision. Our analysis draws on the official MCP specification, IETF RFCs, security research disclosures, vendor documentation, and community discussions — we research and analyze rather than deploying these systems ourselves. Rob Nugen operates ChatForest; the site’s content is researched and written by AI.

The Two Worlds: Stdio vs. Remote Auth

Before diving into OAuth flows and token management, understand the fundamental split in MCP authentication:

Stdio servers run as subprocesses on your machine. Claude Desktop, Cursor, and VS Code launch them under your user account. The operating system provides access control — only processes running as your user can talk to the server. Credentials for upstream APIs (GitHub tokens, database passwords) are passed via environment variables, not OAuth flows. The MCP specification is explicit: “Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.”

Remote servers are HTTP endpoints accessible over the network. Anyone who knows the URL can attempt to connect. This is where OAuth 2.1 becomes mandatory. The current MCP specification requires authorization servers to implement OAuth 2.1, and MCP servers intended for public use to publish Protected Resource Metadata and validate token audience — in effect requiring the full OAuth 2.1 authorization flow with PKCE for public remote servers.

For internal team tools and personal remote servers, simpler approaches — static Bearer tokens or API keys in the Authorization header — are acceptable and often preferable. But for anything public-facing, the spec mandates OAuth.

How the Auth Spec Evolved: A Timeline

The MCP authorization specification went through four major revisions, each fundamentally changing how authentication works:

March 2025 — The Original Design

The initial spec coupled the MCP server and authorization server into a single entity. The MCP server was responsible for issuing tokens, managing client registrations, and validating credentials — all on top of serving MCP tools and resources. Every MCP server author had to build a full OAuth authorization server, manage token databases, handle client registrations, and implement consent flows — enormous implementation complexity for what should have been a tool-serving endpoint.

June 2025 — The Great Separation

The June revision made the critical architectural change: MCP servers became OAuth Resource Servers only. Token issuance and client management were delegated to separate, dedicated authorization servers. This meant MCP server authors could rely on existing identity providers (Auth0, Keycloak, Okta) rather than building their own.

Key additions:

• Protected Resource Metadata (RFC 9728) — MCP servers publish metadata documents telling clients where to find their authorization server
• Resource Indicators (RFC 8707) — Tokens are bound to specific MCP servers, preventing token reuse across services
• Dynamic Client Registration (RFC 7591) remained the primary registration mechanism

November 2025 — CIMD Recommended

The November 2025 revision brought the specification closer to enterprise reality:

• Client ID Metadata Documents (CIMD) were added as the recommended client registration mechanism alongside Dynamic Client Registration. Instead of servers issuing client IDs on demand, clients publish a static metadata document at an HTTPS URL. The URL itself becomes the client ID.
• Incremental scope consent via WWW-Authenticate was formalized.
• Protected Resource Metadata discovery was aligned with RFC 9728, making the WWW-Authenticate header’s resource_metadata optional with a .well-known fallback.

July 2026 — Issuer Validation and DCR Deprecation

The 2026-07-28 specification revision — the current spec as of this writing — tightened authorization further, closing a real gap the earlier revisions left open:

• Authorization Server Issuer Identification (RFC 9207): authorization servers should return an iss parameter in the authorization response, and MCP clients MUST validate it against the recorded issuer before redeeming an authorization code — closing an authorization-server mix-up attack vector.
• Dynamic Client Registration (RFC 7591) is now formally deprecated as a registration mechanism (retained only for backwards compatibility with authorization servers that don’t support CIMD) — CIMD is the specified default going forward.
• Client credentials are bound to the issuing authorization server: clients must key persisted credentials by issuer identifier and re-register if the authorization server changes.
• MCP clients must specify an application_type during DCR to avoid OpenID Connect redirect-URI conflicts.

The rest of this guide describes the current (2026-07-28) flow; where earlier-revision behavior differs, it’s noted inline.

Sources: 2025-11-25 changelog, 2026-07-28 changelog.

The OAuth 2.1 Authorization Flow in MCP

Here’s how the complete authorization flow works in the current (2026-07-28) specification:

Step 1: Discovery

The client makes an unauthenticated request to the MCP server. The server responds with HTTP 401 Unauthorized and a WWW-Authenticate header pointing to its Protected Resource Metadata:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="tools:read"

The client fetches the metadata document, which contains the authorization_servers field — a list of authorization servers that can issue valid tokens for this MCP server.

Step 2: Authorization Server Metadata

The client discovers the authorization server’s capabilities by fetching its metadata document at the well-known URI. This tells the client:

• What grant types are supported
• Whether CIMD is supported (client_id_metadata_document_supported: true)
• What scopes are available
• Where the authorization and token endpoints are
• What PKCE challenge methods are supported

Step 3: Client Registration

Three options, in priority order:

1. Pre-registered credentials — Use a client ID that was already configured for this authorization server
2. Client ID Metadata Documents — If the AS supports CIMD, the client uses its metadata document URL as the client_id. The AS fetches and validates the document at authorization time
3. Dynamic Client Registration — Legacy fallback: the client registers with the AS and receives a client ID

Step 4: Authorization Code Flow with PKCE

The client generates PKCE parameters (code_verifier and code_challenge using S256), opens the user’s browser to the authorization endpoint, and includes:

• The code_challenge
• The resource parameter (the MCP server’s canonical URI)
• The requested scope

The user authenticates, reviews the consent screen, and approves. The AS redirects back with an authorization code — and, as of the 2026-07-28 revision, an iss parameter identifying the issuing authorization server (RFC 9207). The client MUST validate this against the authorization server it originally recorded before proceeding — this closes an authorization-server mix-up attack where a malicious or compromised AS could otherwise substitute itself mid-flow.

Step 5: Token Exchange

The client exchanges the authorization code for tokens at the token endpoint, including:

• The code_verifier (proving it initiated the request)
• The resource parameter again (binding the token to the MCP server)

The AS returns an access token (and optionally a refresh token).

Step 6: Authenticated MCP Requests

Every subsequent HTTP request to the MCP server includes:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

The MCP server validates the token — confirming it was issued by a trusted authorization server, intended for this specific server (audience validation), and carries sufficient scopes.

Client ID Metadata Documents: The New Default

CIMD is the most significant practical change in the November 2025 spec. Here’s why it matters and how it works.

The Problem with Dynamic Client Registration

Dynamic Client Registration (DCR) allowed any client to register with any authorization server automatically. This was convenient for experimentation but problematic at scale:

• No client identity verification — the AS has no way to verify who the client claims to be
• Registration spam — bots could register thousands of client IDs
• Enterprise incompatibility — most enterprise identity providers don’t support DCR or restrict it heavily
• Security surface — every registration endpoint is an attack surface

How CIMD Works

Instead of registering dynamically, the client publishes a JSON metadata document at a stable HTTPS URL:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

The URL itself (https://app.example.com/oauth/client-metadata.json) serves as the client_id. When the client initiates an authorization flow, the AS fetches this URL, validates the document, and uses it to configure the client’s OAuth session.

Why CIMD Is Better

CIMD Limitations

CIMD doesn’t solve everything. Authorization servers must still guard against:

• SSRF attacks — a malicious client could submit a client_id URL pointing to internal infrastructure
• Localhost redirect risks — attackers can claim any client’s metadata URL and bind to localhost to capture authorization codes
• No revocation mechanism — there’s no standard way to revoke a CIMD-based client

Protected Resource Metadata and Discovery

RFC 9728 (OAuth 2.0 Protected Resource Metadata) is the backbone of MCP’s authorization discovery. Every remote MCP server MUST implement it — publishing a metadata document telling clients where to authenticate.

Discovery Flow

1. Client sends unauthenticated request → server returns 401 with WWW-Authenticate header
2. Client extracts resource_metadata URL from the header (or falls back to well-known URI probing)
3. Client fetches Protected Resource Metadata → document contains authorization_servers list
4. Client fetches Authorization Server Metadata → discovers endpoints, capabilities, supported PKCE methods
5. Client proceeds with OAuth flow using discovered endpoints

Well-Known URIs

If the WWW-Authenticate header doesn’t include resource_metadata, clients probe well-known URIs:

• https://example.com/.well-known/oauth-protected-resource/mcp (path-specific)
• https://example.com/.well-known/oauth-protected-resource (root)

For authorization server metadata:

• https://auth.example.com/.well-known/oauth-authorization-server/tenant1 (OAuth 2.0)
• https://auth.example.com/.well-known/openid-configuration/tenant1 (OIDC)

Scope Management and Step-Up Authorization

The spec introduces a sophisticated scope management pattern. Instead of requesting all permissions upfront, clients start with minimal scopes and escalate when needed:

1. Client requests initial scopes based on the 401 response’s scope parameter
2. If a tool call requires additional permissions, the server returns 403 Forbidden with error="insufficient_scope" and the required scopes
3. Client computes the union of previously granted scopes and newly required scopes
4. Client initiates a new authorization flow with the combined scope set
5. Client retries the original request with the new token

This pattern reduces initial permission requests and follows the principle of least privilege.

Real-World Vulnerabilities: What Went Wrong

The MCP auth ecosystem’s first major security crisis hit in mid-2025, revealing fundamental implementation flaws that affected production deployments.

Consent Bypass Attacks (July–August 2025)

Security researchers at Obsidian Security discovered that MCP servers acting as OAuth proxies used a single static client_id for all connecting MCP clients. This created a devastating attack chain:

1. Shared consent cache: Once a user grants consent for the proxy’s client_id, the upstream SaaS authorization server remembers that decision. Subsequent requests from any MCP client see the same client_id and skip the consent prompt.
2. Attacker-initiated flow: An attacker completes the MCP consent layer themselves, then sends the resulting redirect URL to the victim. The victim lands at the SaaS authorization endpoint without realizing an attacker initiated the flow.
3. Token capture: The victim completes authentication, and the authorization code goes to the attacker’s controlled redirect URI.

Real-world impact: The Square MCP server (mcp.squareup.com) was affected — attackers could gain access to merchant data, transaction history, and payment infrastructure through a single crafted link.

The Confused Deputy Problem

MCP servers that hold OAuth tokens for multiple users but fail to properly isolate actions create classic confused deputy vulnerabilities. An attacker tricks the server into using another user’s credentials by exploiting the token-to-session mapping.

Mitigation: Use token exchange (RFC 8693) rather than passing OAuth tokens through to downstream services directly — this preserves per-request accountability and ensures each call carries the correct user context, instead of a single shared service-account token standing in for every user.

CVE-2025-6514: mcp-remote Command Injection

The popular mcp-remote OAuth proxy library — downloaded more than 437,000 times by the time of disclosure — was vulnerable to a critical attack (CVSS 9.6): a malicious MCP server could respond with an authorization_endpoint value containing a crafted URI. The proxy passed this value to the Node.js open package to launch a browser; on Windows, open builds a PowerShell command from the URI, and JFrog researchers showed that a non-standard scheme using PowerShell’s $( ) subexpression operator (e.g. "a:$(cmd.exe /c whoami)") achieved full arbitrary command execution on the developer’s machine.

CVE-2025-49596: MCP Inspector RCE

Anthropic’s own MCP Inspector tool had a critical remote code execution vulnerability (CVSS 9.4), caused by the Inspector’s proxy component accepting unauthenticated connections with permissive CORS defaults. Oligo Security, which disclosed the flaw, described chaining it with “0.0.0.0 Day” — a known browser flaw that lets a malicious website reach services bound to all network interfaces — so that simply visiting a malicious site could trigger remote code execution on a developer’s machine.

Timeline and Response

• July–August 2025: Vulnerabilities discovered and responsibly disclosed
• Late September 2025: Vendors deployed fixes
• November 25, 2025: MCP specification updated its Security Best Practices guidance
• July 28, 2026: MCP specification added mandatory authorization-server issuer validation (RFC 9207), closing a related mix-up class of attack

Lessons Learned

These vulnerabilities revealed systemic issues, not just individual bugs:

1. Static client IDs for proxies are dangerous — each dynamically registered client needs its own consent flow
2. Token audience validation is non-negotiable — servers must verify tokens were issued specifically for them
3. Never pass untrusted URLs to OS process-launching functions — validate and sanitize all metadata endpoints before opening them
4. Cookie-based consent state is fragile — __Host- prefix cookies and strict same-site policies are essential
5. Defense in depth matters — consent screens must display client identity, redirect destination, and requested permissions clearly

Additional Security Risks and Mitigations

Beyond the disclosed CVEs above, several structural risks apply to any MCP authorization deployment, not just the specific implementations that were breached:

Over-Permissioned Tokens

Tokens granted to MCP servers are often broader, longer-lived, and less scoped than necessary — an agent that only needs to read Slack messages might receive a token that can also delete channels or manage users.

Mitigation: Adopt the step-up scoping pattern described above — start with minimal permissions and request additional scopes only when a specific tool needs them. Set short token lifetimes and rely on refresh tokens for ongoing access rather than issuing long-lived access tokens.

Token Storage and Theft

MCP configuration files often store API keys and tokens in plaintext JSON files on disk — an easy target for malware or anyone with local filesystem access.

Mitigation: Use the operating system’s credential store (Keychain on macOS, Credential Manager on Windows) instead of plaintext config files, and let the OAuth flow handle token lifecycle automatically rather than hardcoding long-lived secrets.

Malicious Server Token Replay

Without Resource Indicators (RFC 8707), a compromised MCP server could take a token it receives from a client and replay it against a different server the same client is authorized to use.

Mitigation: Always include the resource parameter in authorization and token requests (Steps 4–5 above), and confirm your authorization server enforces audience restrictions on the tokens it issues.

Consent Fatigue

If every MCP server connection triggers a full browser-based OAuth flow, users tend to start clicking “Approve” without reading the requested scope list — undermining the consent model the whole flow depends on.

Mitigation: Cache authorization grants where appropriate, group related servers under the same authorization server when possible, and keep consent screens specific about exactly what’s being requested.

Enterprise Patterns: SSO, Gateways, and Token Propagation

For organizations deploying MCP at scale, the spec’s OAuth flow is just the starting point. Enterprise deployments need to integrate with existing identity infrastructure.

The Enterprise Gap

The MCP maintainers’ own 2026 roadmap lists “Enterprise Readiness” as a priority area precisely because the spec doesn’t yet address these gaps, and Solo.io has documented the SSO gap in detail:

• No gateway authorization-propagation standard — the roadmap names this directly: “well-defined behavior when a client does not connect directly to a server but routes through an intermediary,” including “authorization propagation” and “what the gateway is allowed to see”
• No configuration portability — the roadmap also flags the lack of “a way to configure a server once and have that configuration work across different MCP clients”
• No SSO integration path — as Solo.io puts it, “SSO gives you user identity. What you need is user authorization: OAuth access tokens scoped to specific SaaS APIs on behalf of a specific user” — the spec doesn’t define how a gateway should broker that exchange
• Authorization server discovery per-server — every MCP server points to potentially different authorization servers, creating a fragmented discovery landscape

Gateway-Based Authorization

The dominant enterprise pattern emerging is the MCP gateway — a centralized proxy that sits between clients and servers:

MCP Client → MCP Gateway → MCP Server A
                         → MCP Server B
                         → MCP Server C

The gateway handles:

• Authentication — validates tokens from the enterprise IdP (Okta, Entra ID, Auth0)
• Authorization — applies RBAC policies per tool, per server
• Token exchange — uses RFC 8693 (OAuth 2.0 Token Exchange) to swap broad access tokens for narrowly-scoped tokens per downstream MCP server
• Audit logging — records every tool invocation with user identity
• Rate limiting — prevents runaway agent token consumption

Notable implementations:

• Kong MCP Gateway — extends Kong’s API gateway with MCP-aware routing and a dedicated MCP OAuth 2.1 authentication plugin
• Agent Gateway (agentgateway.dev) — open-source (Apache 2.0), Linux Foundation-hosted MCP gateway with built-in OAuth support, now also offered as “Solo Enterprise for agentgateway” by Solo.io
• Red Hat — published advanced authentication and authorization patterns for its Envoy-based MCP Gateway, using Kuadrant for enterprise-grade security
• TrueFoundry MCP Gateway — enterprise-focused with RBAC enforced per user/team at the gateway

SSO Integration Pattern

The recommended enterprise pattern for SSO integration:

1. User authenticates to enterprise IdP (Okta, Entra ID, etc.) via standard SSO flow
2. Gateway receives JWT with user identity, group memberships, and roles
3. Gateway applies RBAC policies — maps roles to allowed MCP servers and tools
4. Gateway performs token exchange — obtains server-specific tokens from the MCP server’s authorization server
5. Downstream MCP server validates the exchanged token normally

This pattern means MCP servers don’t need to know about the enterprise IdP at all. The gateway translates between enterprise identity and MCP OAuth.

Cross-Application Access (XAA)

When MCP tool invocations trigger downstream API calls, the question of token propagation becomes critical. Cross-App Access (XAA), referenced in the MCP maintainers’ own roadmap as a path toward “enterprise-managed auth,” is the emerging pattern — it uses an OAuth Identity Assertion Authorization Grant (ID-JAG), a signed delegation token the identity provider issues once, so:

• MCP servers must not forward client tokens to downstream services (this is the confused deputy problem)
• Instead, downstream services receive tokens issued directly by the IdP, scoped via the ID-JAG grant
• Each service boundary requires its own token, with its own audience and scope

Auth Provider Integration

Several identity platforms now offer specific MCP integration support:

Keycloak (Open Source)

Keycloak published official documentation for using it as an MCP authorization server, starting with version 26.4/26.5. It can serve as the authorization server for MCP servers, handling:

• Client registration (DCR and CIMD)
• Token issuance with audience-restricted JWTs
• Consent management
• PKCE validation

Good choice for teams that want full control over their identity infrastructure without vendor lock-in.

Auth0

Auth0 published MCP integration guides covering Protected Resource Metadata, token management, and scope design. Their own open-source auth0-mcp-server automatically redacts sensitive fields (client_secret, token) as [REDACTED] in tool responses so secrets don’t leak into an AI assistant’s context. Auth0’s platform also supports:

• CIMD-based registration
• Fine-grained scope mapping to MCP tools
• Step-up authentication for sensitive operations
• MFA integration

Stytch

Stytch offers MCP-specific OAuth flows with:

• Email, social login, SSO, and MFA support
• Permission mapping to MCP tools
• Consent page customization
• Token lifecycle management

Okta / Entra ID

Enterprise IdPs that work as upstream authorization servers, typically behind an MCP gateway rather than directly. Okta has published an open-source Okta MCP server for managing Okta itself via natural-language commands.

Descope

Descope’s Agentic Identity Hub treats AI agents as first-class identities alongside human users, offering OAuth 2.1 and PKCE support for exposing MCP servers, with granular per-agent and per-tool scopes assignable to MCP clients.

mcp-auth.dev

An open-source library specifically for adding MCP-compliant authentication to servers. Provides:

• Spec-compliant OAuth 2.1 flows
• Protected Resource Metadata serving
• Token validation middleware
• PKCE enforcement

Cloudflare Workers

Cloudflare published a comprehensive MCP authorization implementation for Workers-based MCP servers, including the workers-oauth-provider library, which offers:

• Built-in OAuth 2.1 handling
• Durable Objects for session persistence
• Token storage and refresh
• Integration with Cloudflare Access for enterprise SSO

Practical Implementation Guidance

For Local/Stdio Servers

If your MCP server runs as a local subprocess (the vast majority of current MCP servers):

1. Don’t implement OAuth — it’s unnecessary and the spec says not to
2. Use environment variables for upstream API credentials
3. Reference secrets with ${env:VAR} syntax in configuration files — never hardcode them
4. Never commit secrets to mcp.json or configuration files

Example Cursor configuration for a stdio server:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["server.js"],
      "env": {
        "GITHUB_TOKEN": "${env:GITHUB_TOKEN}",
        "DATABASE_URL": "${env:DATABASE_URL}"
      }
    }
  }
}

For Internal/Team Remote Servers

If your MCP server is remote but only serves your team:

1. Static Bearer tokens are fine — configure a long-lived API key and pass it in the Authorization header
2. Rotate tokens periodically — use your team’s standard secret rotation practices
3. Add IP allowlisting if possible — restrict access to known IP ranges
4. Log all access — even trusted internal servers should audit who calls what

For Public Remote Servers

If your MCP server is publicly accessible:

1. Implement the full OAuth 2.1 flow — there’s no shortcut
2. Use an existing auth provider — Auth0, Keycloak, Stytch, or Cloudflare Workers auth. Don’t build your own authorization server
3. Publish Protected Resource Metadata at the well-known URI
4. Support CIMD — it’s the recommended registration mechanism
5. Validate token audiences — ensure tokens were issued specifically for your server using RFC 8707 resource indicators
6. Implement step-up authorization — start with minimal scopes, escalate when needed
7. Never pass through tokens — if your server calls upstream APIs, obtain separate tokens for those services

Security Checklist

For any MCP server handling authentication:

• All endpoints use HTTPS
• PKCE is required for all clients (S256 method)
• Tokens are validated for audience (not just signature)
• Redirect URIs are validated against pre-registered values exactly
• Consent screens display client identity and redirect destination
• Refresh tokens are rotated for public clients
• No tokens are logged or stored in plaintext
• Authorization metadata endpoints don’t accept arbitrary URLs (SSRF protection)
• Cookie consent state uses __Host- prefix
• Each downstream service gets its own token (no token passthrough)

The 2026 Roadmap and What’s Coming

The MCP maintainers’ roadmap lists “Enterprise Readiness” as one of four priority areas. Key areas under development:

Enterprise Working Group

The roadmap states: “We expect an Enterprise WG to form” to own enterprise-readiness work, with focus areas including:

• Gateway and proxy patterns, including authorization propagation
• Enterprise-managed auth (SSO-integrated flows via Cross-App Access, replacing static client secrets)
• Configuration portability across environments
• Audit trails and observability enterprises can feed into existing compliance pipelines

The roadmap notes these are not commitments — “some items may not materialize at all” — and much of the output is expected to land as optional extensions rather than core spec changes.

Authorization Extensions

The MCP Authorization Extensions repository tracks additional authorization mechanisms beyond the core spec. Extensions are optional, additive, and composable — implementations can adopt multiple extensions without conflicts.

Remaining Gaps

Despite the July 2026 improvements, significant gaps remain:

• Authorization propagation through gateways — no standard for how downstream servers learn about original client authorization
• Token caching strategies — the spec doesn’t address how clients should cache and reuse tokens across reconnections
• Machine-to-machine flows — client_credentials grant support is minimal; most guidance assumes interactive user flows
• Revocation propagation — no mechanism for real-time token revocation notification across federated MCP deployments

Decision Guide: Choosing Your Auth Strategy

Related ChatForest Guides

For broader MCP context, see our related guides:

• MCP Server Security — transport security, input validation, sandboxing
• MCP Gateway and Proxy Patterns — gateway architectures, routing, load balancing
• MCP Multi-Tenant Patterns — tenant isolation, data partitioning
• MCP in Production — deployment, monitoring, operational patterns
• MCP Transports Explained — stdio, SSE, Streamable HTTP transport details
• Debugging MCP Servers — troubleshooting connection and auth issues
• Building MCP Clients — client-side implementation guidance
• MCP Server Deployment & Hosting — hosting options and deployment strategies
• MCP Reaches the IETF — IETF drafts proposing cryptographic security layers (MCPS Agent Passports) beyond OAuth
• Pinterest’s MCP Ecosystem Case Study — production JWT + mesh identity auth pattern at enterprise scale