PKCE for MCP

How PKCE for MCP Works

PKCE for MCP adds a proof step to the login flow so the party that began authentication must later present the matching verifier. That makes the authorization code less useful if it is intercepted, because the code alone is no longer enough to complete the exchange.

In practice, this matters most when an AI agent or client is driving the flow on behalf of a user. The proof is lightweight, but it changes the security boundary: the code becomes tied to the original client instance rather than being a reusable token that can be replayed elsewhere.

Why It Matters for OAuth-Based Tool Access

MCP commonly relies on OAuth-style authorization to let a client reach tools, resources, or downstream data. PKCE strengthens that pattern by reducing the value of intercepted front-channel material and making the login flow safer for public clients, embedded clients, and other environments where a secret cannot be fully trusted to stay confidential.

This is especially relevant in agentic workflows, where a login step may happen through a browser, an app shell, or a delegated client path. The control does not replace OAuth, it narrows one of OAuth’s most common abuse paths by binding the exchange to the client that initiated it.

For the protocol-level model, see the Model Context Protocol authorization specification and the RFC 9700: Best Current Practice for OAuth 2.0 Security.

What PKCE Does Not Solve

PKCE protects the code exchange, not the rest of the authentication and authorization stack. A weak redirect URI, a compromised client, poor token handling, or excessive downstream permissions can still expose the system even when PKCE is implemented correctly.

It also does not make every MCP client trustworthy by itself. If a client can be tricked into starting a flow for the wrong resource, or if tokens are passed around too freely after issuance, the attacker may still achieve unauthorized access through another route.

When to Treat It as a Required Control

PKCE should be treated as a baseline control for MCP login flows that rely on browser-based or public-client style authorization. It is most important where the client cannot safely store a secret, where the authorization code could be observed in transit, or where multiple tools and integrations share the same sign-in path.

Good practice is to pair it with strict redirect URI validation, tight token audience handling, and careful review of how the MCP client exchanges and stores credentials. The point is not only to “add PKCE”, but to make sure the whole login path is designed so that a stolen code does not become a reusable access grant.

Use the MCP Security Guide for the broader OAuth-based authorisation model, and the OAuth 2.0 and OpenID Connect Guide for Identity Teams for the PKCE mechanics behind authorization code protection.

Risk and Threat Considerations

PKCE reduces a specific replay risk, but the surrounding MCP flow can still be abused if attackers intercept codes, tamper with redirects, or exploit weak client handling. The main danger is not the code alone, it is the possibility that an intercepted authorization response becomes a live session or token grant.

Failure mechanism: An attacker captures an authorization code before it is redeemed, then tries to exchange it from a different client or environment where the original proof is missing or mishandled.

Impact: The attacker may gain unauthorized access to MCP tools, upstream APIs, or connected data sources, especially if the resulting token is broadly scoped or long lived.

Practitioner Guidance

Why practitioners should care: PKCE is one of the simplest ways to harden MCP login flows without changing the user experience, but it only works when the client and authorization server both enforce it correctly. For MCP deployments, treat it as part of the authentication design, not as an optional enhancement.

What to watch for: Pay close attention to flows that rely on embedded browsers, custom clients, or shared redirect handling, because those are the places where code interception and replay risks tend to surface. Validate that the proof exchange is mandatory and that the client cannot silently bypass it.

Related resources from NHI Mgmt Group

• What is the difference between PKCE and infrastructure-asserted identity in MCP authorization?
• Why do OAuth 2.1, PKCE and DCR become hard for MCP deployments?
• What is the Model Context Protocol (MCP) and why does it matter for security?
• What is MCP Step-Up Authorisation and how does it implement least privilege for agents?