MCP Authentication Implementation Patterns With Examples

MCP authentication implementation patterns solve three different problems, namely delegated user access, unattended agent access, and workforce governance. Platform teams need one MCP control plane so they can use those patterns across AI projects without rebuilding the security plumbing for each one. The practical design combines OAuth identity with centralized credential management, tool-call policy, runtime monitoring, and audit records rather than treating a successful login as permission to do everything.

Why MCP authentication is now an engineering problem, not a configuration detail

Anthropic introduced MCP in November 2024 without mandatory authentication requirements for remote servers, reflecting the protocol’s origins as a local tool. The March 2025 revision introduced OAuth 2.1 as the mandatory framework for HTTP-based flows. Production use changed the job of the implementer. Connecting a client to a server was no longer enough, because the server also needed to establish whose authority supported each request.

That distinction produces three patterns, each built around a different principal. User-delegated access lets an agent act with a human’s approval, while Client Credentials gives an unattended agent its own identity. With Enterprise-Managed Authorization, the organization’s identity provider controls access for its workforce. These are not interchangeable levels of security. Choosing one requires knowing who is acting, who grants permission, and where that permission must stop.

What the July 2026 spec actually changed and what it didn't

The June 18, 2025 revision already required Protected Resource Metadata under RFC 9728 and Resource Indicators under RFC 8707. Servers must share metadata that tells clients where authorization happens. Authorization requests and token requests must also include a resource parameter naming the target MCP server’s canonical URI, which the authorization server places in the token’s aud claim. A valid signature is not enough on its own. The server that receives a token must reject it if its audience does not match the server’s own URI.

The July 28, 2026 revision adds issuer validation under RFC 9207 to stop authorization-server mix-up attacks. Authorization servers SHOULD include an iss parameter in their responses, and clients receiving it MUST compare it with the recorded issuer and refuse a mismatch. Pre-registered credentials come first, while Client ID Metadata Documents, or CIMD, become the recommended choice when there is no existing relationship. Dynamic Client Registration, or DCR, is deprecated, but backward compatibility will last for twelve months.

The revision also formalizes refresh-token handling and clarifies scope accumulation during step-up authorization. Clients must state their OpenID Connect application_type when they register. This avoids a concrete failure for CLI clients. An authorization server that defaults a CLI client to “web” can reject its localhost redirect URI, so registration metadata is part of getting the flow right.

The largest architectural change is the stateless core. The Mcp-Session-Id header and initialize/initialized handshake are gone, while protocol version, client identity, and capabilities travel in _meta on every request. Servers can sit behind a plain round-robin load balancer without sticky routing, but each call must carry authorization because a past handshake is no longer enough. Teams using a stateful cookie keyed to client_id need to revisit that design. Across multiple agent teams, centralized enforcement through a control plane such as Runlayer becomes the shared policy layer rather than another piece of connection logic each team rebuilds.

OAuth 2.1 with PKCE for user-delegated access — when a human is behind the request

When a human initiates work through an agent, Authorization Code with PKCE ties access to an explicit approval step. The client generates a random code_verifier and sends its SHA-256 hash, the code_challenge, with the authorization request. It later presents the verifier directly to the token endpoint. The authorization server issues tokens only if hashing that verifier reproduces the original challenge, so an intercepted authorization code alone is insufficient. The verifier never travels through the browser redirect.

MCP requires the stronger S256 method whenever it can be used. This protection is especially useful for desktop applications and CLI tools that cannot keep a client secret, but it does not protect a compromised runtime holding the verifier. Approval also needs narrow limits. The agent cannot exceed the user’s permissions, and it should request only the scopes needed for the specific tool call. Separately, the resource parameter binds the token to the intended MCP server through its audience claim.

The most consequential boundary appears when that server calls an upstream API. An inbound token is not a universal pass. Forwarding it upstream without exchange violates the spec and creates a confused-deputy risk, because a token issued for one resource is being used at another. Instead, the MCP server validates the inbound token against its own authorization server, extracts the client identity and scope, and obtains a short-lived upstream token scoped to the operation. OAuth 2.0 Token Exchange under RFC 8693 provides this on-behalf-of pattern.

That exchange separates permission to use the MCP server from permission to act on the downstream service. Auth0 by Okta made MCP authentication generally available in May 2026, including CIMD registration and on-behalf-of token exchange. Cloudflare’s workers-oauth-provider library implements the OAuth 2.1 provider side inside a Cloudflare Worker, including PKCE and discovery endpoints. It stores tokens by hash without persisting plaintext. These examples address implementation work, but the downstream authority boundary still has to be designed correctly.

OAuth Client Credentials for unattended agents — when there is no user in the loop

A scheduled or autonomous agent has no human approval to delegate. Borrowing a user identity hides the lack of human approval. The Client Credentials extension lets the agent authenticate directly to the authorization server with its own client ID and secret, or a signed assertion. It receives a token representing its own authority and attaches it to each MCP request. The server must enforce the agent’s permission set on its own, apart from any user profile.

The direct flow is simple, but credential sprawl is not. Creating credentials for every agent, integration, and workflow quickly becomes difficult to govern when they are scattered across environment files and vaults. Teams running more than a handful of production agents need centralized storage, rotation, and auditing. Yet credential management does not prove which runtime presents a token. A stolen credential can look legitimate, so cryptographic workload identity remains a separate requirement.

An ephemeral credential broker limits the authority available to each task. When an orchestrator spawns an agent, it asks the broker for the access that task needs. The broker checks the request against the application’s permission limit and issues a narrowly scoped token valid for no longer than the task. Task duration becomes an authorization boundary. That time limit is compatible with a stateless protocol because it constrains the credential independently of protocol session state.

Delegation adds another boundary when agents spawn sub-agents. Each hop should have a signed record of who authorized whom, when, and with what scope, and permissions can only narrow. Both agents should present and verify credentials before exchanging data. Otherwise, a claimed role can substitute for proven authority. For deployments that cannot route authentication through a cloud IdP, Keycloak supports self-hosted Client Credentials flows, including air-gapped and regulated environments.

Enterprise-Managed Authorization for workforce deployments — when the organization sets the rules

Enterprise-Managed Authorization, or EMA, stabilized on June 18, 2026 as an optional MCP extension. It lets an organization use an existing identity provider, such as Okta or Microsoft Entra ID, to control which MCP servers and scopes employees can access. The organization sets the available choices before individual consent. SSO, SCIM-based provisioning, and centralized revocation connect MCP access to the employee lifecycle, so role changes and departures follow the same identity process as other access.

EMA governs people. It does not establish workload identity for an autonomous agent running without a user, and standardized agent identity and delegation remain active areas of development. Unattended workloads still need Client Credentials. Even for employees, permission to reach a server can be too broad if its tools expose more authority than the work requires. The architecture therefore has two decisions, establishing identity and then enforcing tool permissions.

Provider compatibility can complicate the first decision before teams reach the second. Providers designed around static registration and standard OAuth flows can require workarounds for CIMD, Protected Resource Metadata, and Resource Indicators. Auth0’s May 2026 release includes Resource Parameter Compatibility Mode, while its Cross App Access enterprise federation is Early Access. Stytch Connected Apps has explicit MCP support and a public Cloudflare partnership for remote servers.

Runlayer addresses the composition layer through SSO and SCIM integration that ties employee identity to MCP actions, with policy enforced at tool-call depth. That is a different role from issuing an access token. An IdP decides which workforce identity and scopes are valid, while a tool-level policy layer governs the permitted action.

How should multiple AI teams choose and combine MCP authentication patterns?

If a specific human initiates the request, use Authorization Code with PKCE and keep the agent’s authority within that person’s permissions. If an autonomous agent acts on its own, use Client Credentials with a registered agent identity and ephemeral credentials. Work done by sub-agents also needs signed records of delegation. If the human-facing deployment spans a workforce with a central IdP, layer EMA over user-delegated access rather than leaving each project to maintain separate consent arrangements. EMA and Client Credentials run in parallel when an organization has both kinds of work.

If the server uses stdio, authentication belongs to the environment, including credentials read from environment variables. If it uses HTTP or Streamable HTTP, the OAuth patterns apply, and it must support Protected Resource Metadata and Resource Indicators. For new registration work without pre-existing credentials, build against CIMD, the recommended replacement for deprecated DCR. That choice avoids creating another migration task.

If the MCP server calls an upstream API, perform token exchange regardless of the inbound pattern. Never forward the inbound token as a shortcut. For a shared enterprise design, EMA governs workforce access, Client Credentials with broker-issued tokens governs autonomous agents, and token exchange handles downstream calls. Tool-level policy then applies to each of those identity paths.

What the spec leaves open — the gaps that implementation patterns cannot close alone

The NSA’s May 2026 guidance states that MCP “currently lacks support for exchanging Role Based Access Control (RBAC) permissions at instantiation”. Authentication therefore leaves the protocol without a permission model for every tool. At enterprise scale, shadow MCP usage compounds that gap because platform and security teams cannot govern connections they cannot see. Runlayer is one option for real-time visibility across MCP connections, agent sessions, and tool calls, with policy enforcement at the depth the protocol does not define.

Workload identity remains distinct from both permissions and visibility. OAuth can validate a credential without proving which software, on which infrastructure, holds it. Cryptographic workload attestation supplies that missing proof. This complements PKCE and Client Credentials rather than replacing either, because protecting an exchange or limiting a token’s scope does not establish the integrity of its holder.

A malicious server can present clean tool definitions during review and then alter them after trust has been established. Hidden instructions in tool responses can also enter the model’s context as trusted input. Correct OAuth flows cannot stop either attack. To detect these attacks, teams need to monitor tool definitions and responses in real time for prompt injection and intent drift that authorization alone cannot spot.

The final gap is evidence of what happened. For compliance and incident response, supplement the credential inventory and session-level grants with an action history in tamper-proof logs tied to individual tool calls. Runlayer’s platform layer includes runtime detection and tamper-proof audit logs with full OTEL tracing tied to SSO and SCIM identity. The EU AI Act reached its general application date on August 2, 2026, with full applicability, including high-risk AI rules, beginning on August 2, 2028, and penalties reaching 7% of global annual turnover for prohibited practices. The organizational test is whether a team can both prove that agents logged in and demonstrate governance over what they did.