How to Secure Remote MCP Servers with OAuth 2.1 and PKCE

MCP OAuth security uses OAuth 2.1-style delegated authorization for remote MCP servers: the client gets a user-approved, short-lived, scoped access token from an authorization server, typically through authorization code flow with S256 PKCE. The MCP server validates the token and permissions before executing tools. OAuth improves on API keys, but secure deployment still requires HTTPS, least privilege, strict validation, and token rotation or revocation.

What MCP OAuth security means

Model Context Protocol (MCP) lets an AI application connect to tools, data sources, APIs, and services. OAuth supplies the delegated authorization layer for protected remote resources.

In practical terms, the MCP client acts on the user’s behalf, the MCP server protects and executes tools, and the authorization server handles sign-in, consent, and token issuance. The MCP server remains responsible for enforcing permissions at the tool boundary. For client-side controls around this flow, see MCP client security checklist.

Remote HTTP MCP deployments are the primary context for this OAuth flow. Local or stdio MCP deployments may use process boundaries, operating-system controls, local configuration, or another authentication arrangement instead of this OAuth flow. For a broader hardening guide for this deployment model, see remote MCP server security guide.

The three MCP OAuth roles

A valid token is not unlimited permission. The MCP server must still confirm that the token is intended for that resource and authorizes the requested tool and operation. The server operator also matters: a vendor-operated, third-party-hosted, or user-controlled server can create different risks for tokens, logs, tools, and sensitive context.

The remote MCP OAuth 2.1 flow

The exact architecture varies by deployment, but a common remote MCP OAuth flow works like this:.

1. Discover metadata. The client discovers the applicable protected-resource and authorization-server metadata rather than relying on unsafe hard-coded assumptions.
2. Register the client where applicable. Some deployments support or require dynamic registration; it is not mandatory in every deployment. Registration should be constrained and validated when used.
3. Request authorization. The client opens a browser-based authorization request so the user can sign in and provide consent.
4. Use S256 PKCE. The public client creates a code verifier and challenge. The authorization server returns a code that can be exchanged only with the matching verifier, reducing authorization-code interception and injection risks.
5. Exchange the code. The client sends the code and verifier to the token endpoint.
6. Receive a scoped token. The authorization server issues access credentials for the approved resource and permissions.
7. Call the MCP server. The client presents the access token on protected MCP requests.
8. Validate before execution. The MCP server checks the token and required permissions before running the requested tool.
9. Manage the lifecycle. Expiration, renewal where applicable, rotation, and revocation limit the useful life of compromised or unnecessary access.

This division of responsibility is central: the authorization server manages identity, consent, and issuance, while the MCP server enforces authorization for each protected request.

Why PKCE, discovery, and redirects matter

S256 PKCE protects the code exchange

S256 PKCE is a core safeguard in the supported MCP OAuth pattern, especially for public clients that cannot safely keep a client secret. It binds the authorization request to the later code exchange. PKCE does not replace HTTPS, token validation, or permission checks.

Metadata discovery avoids unsafe assumptions

Protected-resource and authorization-server metadata helps the client identify the applicable authorization service, endpoints, and resource settings. Clients should validate the discovered information instead of silently applying settings from another deployment.

Redirect handling must be strict

Clients should allow only approved redirect destinations and reject arbitrary callback URLs. For a desktop client using a temporary loopback callback, bind the listener appropriately, accept only the expected callback, restrict its lifetime, and shut it down after the response. Never let an authorization flow choose an arbitrary callback destination.

When dynamic client registration is used, the authorization server should constrain who may register, which redirect destinations are allowed, and what client capabilities are accepted. Pre-registered clients are another deployment option.

Token validation before tool execution

Receiving a bearer token does not prove that a request is authorized. Before executing a protected tool call, the MCP server should check:

• Issuer: Does the expected authorization server issue the token?
• Audience: Is the token intended for this MCP server or protected resource?
• Expiry and status: Is it valid, unexpired, and not revoked or otherwise invalidated?
• Signature or introspection status: Can the server verify it cryptographically or confirm its current status through introspection?
• Scopes and permissions: Does it authorize the requested tool and operation?

Depending on the deployment, validation can use local checks or introspection. The essential rule is consistent enforcement on every protected request.

A practical sequence is:

1. Receive the request over HTTPS.
2. Extract and validate the access token.
3. Check issuer, audience, expiry, signature or introspection status, and required scopes.
4. Map the approved permissions to the requested tool and operation.
5. Reject the request if any required check fails.
6. Execute the tool only after authorization succeeds.

Scopes and least-privilege access

Scopes should be narrow enough to limit the impact of a stolen token, compromised client, or overly broad agent instruction. Prefer permissions that distinguish the tools and operations a task actually needs instead of broad or wildcard access.

For example, an agent that only reads calendar information should not automatically receive permission to modify events or access unrelated data. Exact scope names depend on the deployment, but the principle is consistent: grant only the access required for the task.

Long-running or autonomous agents may use distinct, restricted identities linked to users rather than directly using a user identity. That is a deployment choice, not a universal MCP requirement. Permissions and accountability should remain clear whichever model is selected. For broader server-side hardening guidance, see secure MCP server checklist.

Authorization to invoke a tool does not prove that the tool is safe, that its instructions are trustworthy, or that the server handles data appropriately. Least privilege reduces the blast radius; it does not establish trust.

Token lifecycle and operational safeguards

• Protect storage: Keep access and refresh credentials out of logs, prompts, source code, and exposed client-side storage.
• Limit validity: Use short-lived or otherwise properly managed access tokens where the deployment supports it.
• Control renewal: Use refresh-token rotation where applicable and monitor unusual renewal activity.
• Support revocation: Terminate access when a user, agent, client, or server is no longer trusted.
• Use HTTPS/TLS: Protect remote MCP and authorization traffic in transit.
• Apply gateway controls: Use rate limiting, monitoring, and audit logging where suitable, without exposing secrets in logs.

These measures reduce the useful lifetime and potential impact of leaked credentials and make unusual tool activity easier to investigate.

OAuth compared with API keys and mutual TLS

Static API keys generally represent a fixed application or server-level credential. OAuth can provide delegated, user- or agent-specific access with scopes and revocation, making it better suited to many multi-user and remote-agent scenarios. API keys can still fit some deployments, but they usually offer less-granular delegation and lifecycle control. For a more detailed comparison of these credential models, see OAuth versus API keys for AI agents.

Mutual TLS (mTLS) authenticates a client through certificates and the TLS connection. OAuth instead provides delegated authorization through tokens, consent, scopes, and token lifecycle controls. mTLS can be useful for workload or service identity; OAuth is often more suitable when access must reflect a user, agent, or changing permissions. A deployment may use them together or choose between them based on its trust and operational model.

Authorization servers, identity providers, and frameworks

An external identity provider may authenticate the user, but the component that issues the token accepted by the MCP server must match the resource’s authorization design. Simply copying an external provider’s metadata or forwarding a token does not automatically make that token valid for the MCP server’s audience and permissions.

The authorization server may be external or self-managed. Keep user authentication, consent, token issuance, MCP request validation, and tool execution as distinct responsibilities even when one organization operates several components.

A framework such as FastMCP can help an MCP server expose protocol endpoints, integrate metadata, validate tokens, and reject unauthorized requests, depending on its configuration. It does not replace the authorization server, user consent, identity management, or a sound scope design. Framework features still require review of issuer, audience, expiry, signature or introspection status, and tool permissions. For the wider identity and authorization context, see AI application identity and access guide.

A provider-neutral request guard therefore looks like this:

discover applicable metadata
receive HTTPS request
validate bearer token: issuer, audience, expiry, signature or introspection
check required tool scope
reject on failure; execute only after every check passes

What OAuth does not solve

OAuth protects delegated authorization and access. It does not certify the safety of every MCP server, tool, prompt, dependency, or agent workflow. Risks remain from:. For risks involving the unsafe use of authorized tools, see AI agent tool misuse risks.

• Token leakage: Exposed tokens in logs, prompts, storage, or a compromised server can enable unauthorized access.
• Compromised servers: A server may misuse the access it receives or expose sensitive context.
• Excessive permissions: Broad scopes can turn a compromised client or tool into a high-impact access path.
• Context injection: Untrusted content may influence an agent to request unsafe or unauthorized actions.
• Tool chaining: Individually permitted tools may combine into an outcome beyond the intended task.
• Context leakage: Sensitive information may move among the model, tools, servers, logs, and downstream services.
• Supply-chain exposure: Third-party tools, packages, or servers may contain unsafe behavior or vulnerabilities.

Review the MCP server operator, tool behavior, data handling, deployment configuration, and software supply chain separately from the OAuth configuration.

MCP servers that call downstream APIs

An MCP server may call another API on behalf of the user. That creates a second authorization boundary: the downstream API must receive credentials with the correct permissions and intended audience.

Do not treat an MCP-server credential as a user credential or forward a token to a resource for which it was not intended. A deployment may need an additional delegation or token-exchange design, but there is no single universal architecture.

Review the downstream audience, consent, scopes, server identity, and audit trail before allowing an MCP server to act on another API.

MCP OAuth security checklist

• Use HTTPS/TLS for protected remote communication and authorization traffic.
• Use authorization-code flow with mandatory S256 PKCE for public MCP clients.
• Discover and validate applicable protected-resource and authorization-server metadata.
• Handle redirects securely and constrain registration when registration is used.
• Issue narrow, user- or workload-specific scopes for sensitive tools and operations.
• Validate issuer, audience, expiry, signature or introspection status, and required scopes before tool execution.
• Protect token storage and logs; manage expiration, rotation where applicable, and revocation.
• Use rate limits, monitoring, and audit logs where suitable.
• Review the trustworthiness of the MCP server, tools, deployment, dependencies, and supply chain.
• Assess downstream APIs separately when an MCP server acts on behalf of a user.

OAuth controls delegated authorization and access—not the inherent safety of tools, servers, prompts, or deployments. A secure MCP implementation combines the OAuth flow with least privilege, careful token validation, strong operational controls, and an independent review of what each tool and server can do.

Watch this in video

MCP Gets OAuth: Understanding the New Authorization …

Real-World Lessons from Building Authentication for AI Agents