How to Add Authentication to Your MCP Server — OAuth 2.1, Bearer Tokens, and What the Spec Actually Requires (2026)

You built a remote MCP server. It works. You deployed it to Cloudflare Workers or a VPS and pasted the URL into Claude Desktop. Everything runs perfectly — and then it occurs to you: that URL is public. Anyone who discovers it can call your tools, read your data, and exhaust your API quotas.

Authentication for remote MCP servers is one of the most consistently under-documented parts of the MCP ecosystem. The official specification covers what must be implemented for a spec-compliant public server, but it doesn't tell you what to do when you just want to protect a team tool from unauthorized access without implementing a full OAuth authorization server.

This guide covers the full picture — from the simplest approach (a static Bearer token that takes five minutes) to full OAuth 2.1 with PKCE (which is what public-facing MCP servers genuinely need). It also covers the five security mistakes that real implementations have made — some of which led to one-click account takeovers when discovered.

Why Authentication Matters for Remote MCP

A local stdio MCP server — one that runs as a subprocess on your machine — doesn't need auth. It's only accessible from your machine, launched by Claude Desktop under your user account. The operating system is your access control.

A remote MCP server is fundamentally different. It's an HTTP endpoint, publicly routable, serving requests from any source that knows the URL. Without authentication:

• Anyone who discovers your URL can call your tools — including write operations that modify data
• Your API quotas (OpenAI, database calls, external services) can be exhausted by unauthorized requests
• If your tools access private data, that data is exposed to anyone who probes your endpoint
• Your Cloudflare Workers or server compute costs can be driven up by abuse

The MCP November 2025 specification addresses this directly: remote MCP servers intended for public use must implement OAuth 2.1 with PKCE. For internal or team tools, simpler approaches are acceptable and often preferable.

Three Approaches — Which One Do You Need?

Approach 1 — Bearer Token (Simplest)

For most team tools and personal servers, a static Bearer token is entirely sufficient. The client sends a secret token in the Authorization header with every request. Your server validates it. If it doesn't match, you return 401.

Server-Side: Validate the Token in Your Worker

// In your Cloudflare Worker or MCP server fetch handler:
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Validate Bearer token before routing to MCP
    const authHeader = request.headers.get("Authorization");
    const expectedToken = env.MCP_SECRET_TOKEN; // stored as a Wrangler secret

    if (!authHeader || authHeader !== `Bearer ${expectedToken}`) {
      return new Response("Unauthorized", {
        status: 401,
        headers: { "WWW-Authenticate": "Bearer" },
      });
    }

    // Auth passed — route to your MCP handler
    return McpAgent.serve("/mcp", MyMcpServer)(request, env);
  },
};

Store the secret with Wrangler — never hardcode it:

npx wrangler secret put MCP_SECRET_TOKEN
# Paste your secret when prompted — it's stored encrypted

Client-Side: Configure Claude Desktop

Claude Desktop (and most MCP clients) support static headers for remote server connections. Add your token to ~/.config/claude/claude_desktop_config.json:

{
  "mcpServers": {
    "my-server": {
      "url": "https://my-server.your-account.workers.dev/mcp",
      "headers": {
        "Authorization": "Bearer your-secret-token-here"
      }
    }
  }
}

Generate a Strong Token

# macOS / Linux
openssl rand -base64 32

# Node.js
node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"

When Bearer token is the right choice: you control all the clients, the server is for your team only, and you don't need per-user identity (just "is this caller authorized").

Approach 2 — Cloudflare Access (Zero Code)

If your MCP server runs on Cloudflare Workers, Cloudflare Access can protect it without any changes to your Worker code. Access acts as an identity-aware proxy: it intercepts requests to your Workers URL, challenges unauthenticated users to log in via your configured identity provider (Google, GitHub, Okta, Azure AD, or any SAML/OIDC provider), and only forwards authenticated requests to your Worker.

Setup in the Cloudflare Dashboard

1. Go to Cloudflare Zero Trust → Access → Applications
2. Click Add an Application → Self-hosted
3. Set the Application Domain to your Worker's URL (e.g. my-server.your-account.workers.dev)
4. Configure your identity provider (Google OAuth is the quickest)
5. Create a policy: allow users matching your email domain or specific email addresses
6. Save — Access is now protecting your Worker

Authenticated requests from allowed users pass through. Unauthenticated requests get a Cloudflare Access login page before they reach your Worker at all.

When Cloudflare Access is the right choice: you want SSO via Google/GitHub/Okta for your whole team, you don't want to write auth code, and your server is already on Cloudflare Workers.

Approach 3 — OAuth 2.1 with PKCE (Full Spec)

Full OAuth 2.1 is what the MCP specification requires for public remote servers — servers where users you don't personally know will connect their MCP clients. The flow involves an authorization server, a consent screen, and short-lived access tokens rather than static secrets.

How the OAuth 2.1 + PKCE Flow Works in MCP

PKCE (Proof Key for Code Exchange) is the critical security piece. It prevents an attacker who intercepts the authorization code in step 5 from using it — because to exchange the code for a token, you must provide the original code_verifier that only the legitimate client knows.

The Two Metadata Endpoints Your Server Must Expose

Per the MCP November 2025 spec, your server must implement two well-known endpoints:

// 1. Protected Resource Metadata — RFC 9728
// GET /.well-known/oauth-protected-resource
{
  "resource": "https://your-mcp-server.com",
  "authorization_servers": ["https://your-auth-server.com"],
  "scopes_supported": ["mcp:read", "mcp:write"],
  "bearer_methods_supported": ["header"]
}

// 2. Authorization Server Metadata — RFC 8414
// GET /.well-known/oauth-authorization-server
{
  "issuer": "https://your-auth-server.com",
  "authorization_endpoint": "https://your-auth-server.com/authorize",
  "token_endpoint": "https://your-auth-server.com/token",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code", "refresh_token"]
}

The MCP client fetches these on first connection to discover where to send users for authorization. If these endpoints don't exist, spec-compliant clients cannot complete the OAuth flow.

What the MCP Spec Actually Requires

The November 2025 MCP specification made several requirements non-negotiable for public remote servers. Here's the plain-English version:

OAuth on Cloudflare Workers: workers-oauth-provider

Cloudflare provides a first-party library — workers-oauth-provider — that implements the OAuth 2.1 provider side for Workers. It handles the authorization endpoint, token endpoint, token storage (via KV), and PKCE validation. You configure it with your identity provider of choice.

Setup

npm install workers-oauth-provider

# Create the KV namespace for token storage
npx wrangler kv namespace create "OAUTH_KV"
# Copy the ID it returns into wrangler.jsonc

// wrangler.jsonc additions:
{
  "kv_namespaces": [
    {
      "binding": "OAUTH_KV",
      "id": "YOUR_KV_NAMESPACE_ID"
    }
  ]
}

Implement the OAuth Provider in Your Worker

import OAuthProvider from "workers-oauth-provider";
import { McpAgent } from "cloudflare/agents/mcp";
import { MyMcpServer } from "./mcp-server";

export default new OAuthProvider({
  // Your MCP server URL — used in the Protected Resource Metadata
  apiHandlers: {
    "/mcp": async (request, env, ctx, props) => {
      // props.claims contains the validated token claims
      // props.accessToken is the validated access token
      return McpAgent.serve("/mcp", MyMcpServer)(request, env, ctx);
    },
  },

  // GitHub OAuth as the identity provider
  defaultHandler: async (request, env) => {
    const url = new URL(request.url);

    // Authorization endpoint — redirect to GitHub
    if (url.pathname === "/authorize") {
      const githubAuthUrl = new URL("https://github.com/login/oauth/authorize");
      githubAuthUrl.searchParams.set("client_id", env.GITHUB_CLIENT_ID);
      githubAuthUrl.searchParams.set("scope", "read:user user:email");
      githubAuthUrl.searchParams.set(
        "redirect_uri",
        `${url.origin}/callback`
      );
      return Response.redirect(githubAuthUrl.toString());
    }

    // Callback — exchange GitHub code for access token
    if (url.pathname === "/callback") {
      const code = url.searchParams.get("code");
      const tokenRes = await fetch(
        "https://github.com/login/oauth/access_token",
        {
          method: "POST",
          headers: { Accept: "application/json" },
          body: JSON.stringify({
            client_id: env.GITHUB_CLIENT_ID,
            client_secret: env.GITHUB_CLIENT_SECRET,
            code,
          }),
        }
      );
      const { access_token } = await tokenRes.json();
      // Return the token to the OAuth provider library
      return new Response(JSON.stringify({ access_token }), {
        headers: { "Content-Type": "application/json" },
      });
    }

    return new Response("Not found", { status: 404 });
  },
});

Set your GitHub OAuth app credentials as Wrangler secrets:

npx wrangler secret put GITHUB_CLIENT_ID
npx wrangler secret put GITHUB_CLIENT_SECRET

5 Security Mistakes That Lead to Real Vulnerabilities

These are not theoretical. Several of these mistakes were discovered in production MCP implementations in 2025 and reported as vulnerabilities.

1. Token Passthrough (Most Common)

2. Missing Audience Validation

// Always validate the audience claim:
const payload = jwt.verify(token, publicKey);
if (payload.aud !== "https://your-mcp-server.com") {
  return new Response("Invalid audience", { status: 401 });
}

3. Redirect URI Mismatch (Allows Authorization Code Theft)

4. Missing CSRF State Parameter

5. Storing Tokens in Plaintext

Decision Guide: Which Approach to Use

Frequently Asked Questions

Related Guides

• Build and Deploy an MCP Server on Cloudflare Workers
• Build a Custom MCP Server Using Node.js
• MCP Security in 2026: Tool Poisoning and OWASP MCP Top 10
• Deploy an MCP Server to Production with Docker
• Remote MCP Servers — Test and Connect Online

Resources:

• MCP Authorization Specification — The official spec for OAuth 2.1 in MCP
• Cloudflare Agents: MCP Authorization — Cloudflare's implementation guide
• cloudflare/workers-oauth-provider — GitHub — Official OAuth provider library for Workers
• Auth0: MCP and Authorization — Auth0's guide to MCP OAuth patterns
• Stack Overflow Blog: Auth in MCP — Practical overview of MCP auth patterns
• Obsidian Security: MCP OAuth Pitfalls — Real vulnerability research from 2025
• MCP Playground Online — Test your authenticated MCP server in the browser