What Is MCP Authentication?

MCP authentication is the process by which an MCP server verifies the identity of a connecting MCP client before granting access to its tools, resources, and prompts. Authentication in MCP is transport-dependent: local stdio servers rely on OS process isolation, while remote HTTP/SSE servers require explicit credential verification.

Getting authentication right is critical because MCP tools can take consequential actions — reading sensitive data, writing to databases, executing code. An unauthenticated MCP server exposed to the internet is a serious security risk.

Quick Definition#

MCP authentication is the mechanism that verifies client identity before granting access to server capabilities. It varies by transport: stdio relies on OS-level isolation; HTTP/SSE requires bearer tokens or OAuth 2.1.

Authentication by Transport#

Stdio Transport: OS-Level Isolation#

When a server runs over stdio transport, authentication is handled implicitly by the operating system. The MCP client launches the server as a child subprocess under the same user account. Because the server process inherits the client's OS permissions, there is no separate identity verification step needed — the server can only be reached by that specific client process.

This is secure by default for single-user local deployments, but it does mean that if the client process is compromised, the server is also compromised. For high-security local deployments, run the server subprocess in a restricted OS user account or container.

HTTP/SSE Transport: Explicit Authentication Required#

Remote MCP servers accessible over HTTP must implement explicit authentication. The MCP specification recommends OAuth 2.1 as the authorization framework, but several authentication patterns are used in practice.

Pattern 1: API Key (Bearer Token)

The simplest and most common pattern for developer-facing MCP servers. The client sends a pre-shared secret key in every HTTP request:

Authorization: Bearer mcp_sk_abc123def456

Server-side validation (TypeScript/Express):

import express from "express";

const app = express();

function authenticateRequest(req: express.Request, res: express.Response, next: express.NextFunction) {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    res.status(401).json({ error: "Missing or invalid Authorization header" });
    return;
  }

  const token = authHeader.slice(7); // Remove "Bearer "

  if (token !== process.env.MCP_API_KEY) {
    res.status(403).json({ error: "Invalid API key" });
    return;
  }

  next();
}

// Apply authentication to all MCP endpoints
app.get("/sse", authenticateRequest, async (req, res) => {
  // SSE transport setup
});

app.post("/messages", authenticateRequest, express.json(), async (req, res) => {
  // Message handling
});

Client-side credential passing (TypeScript):

import { SSEClientTransport } from "@modelcontextprotocol/sdk/client/sse.js";

const transport = new SSEClientTransport(
  new URL("https://my-mcp-server.example.com/sse"),
  {
    eventSourceInit: {
      fetch: (url, init) => fetch(url, {
        ...init,
        headers: {
          ...init?.headers,
          "Authorization": `Bearer ${process.env.MCP_API_KEY}`,
        },
      }),
    },
    requestInit: {
      headers: {
        "Authorization": `Bearer ${process.env.MCP_API_KEY}`,
      },
    },
  }
);

Pattern 2: OAuth 2.1 with PKCE

For consumer-facing MCP servers where users authorize access from their accounts, OAuth 2.1 is the correct approach. The MCP specification defines how this works:

1. The server publishes an authorization server metadata document at /.well-known/oauth-authorization-server
2. The client discovers the authorization endpoint from this document
3. The user is redirected to the authorization endpoint and approves access
4. The server issues an access token (and optionally a refresh token)
5. The client uses the access token as a bearer token for all subsequent MCP requests

The MCP spec requires PKCE (Proof Key for Code Exchange) to protect the authorization code flow, even for confidential clients. This prevents authorization code interception attacks.

Minimal OAuth authorization server metadata:

{
  "issuer": "https://my-mcp-server.example.com",
  "authorization_endpoint": "https://my-mcp-server.example.com/oauth/authorize",
  "token_endpoint": "https://my-mcp-server.example.com/oauth/token",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"]
}

Implementing a full OAuth 2.1 authorization server from scratch is complex. For most teams, delegating to an identity provider (Auth0, Okta, Clerk, Supabase Auth) and using their OAuth endpoints is more practical.

Pattern 3: JWT Validation

For organizations that already use JWTs for service-to-service authentication, validating JWTs at the MCP server layer is a clean integration:

import jwt from "jsonwebtoken";

function validateJWT(req: express.Request, res: express.Response, next: express.NextFunction) {
  const token = req.headers.authorization?.replace("Bearer ", "");

  if (!token) {
    res.status(401).json({ error: "No token provided" });
    return;
  }

  try {
    const payload = jwt.verify(token, process.env.JWT_PUBLIC_KEY!, {
      algorithms: ["RS256"],
      audience: "mcp-server",
    });
    // Attach claims to request for downstream authorization
    (req as any).user = payload;
    next();
  } catch (err) {
    res.status(403).json({ error: "Invalid token" });
  }
}

Authentication vs. Authorization#

Authentication (who are you?) and authorization (what are you allowed to do?) are separate concerns in MCP:

• Authentication verifies the client's identity before the connection is accepted.
• Authorization controls which tools and resources the authenticated client can access.

Most simple MCP server implementations treat all authenticated clients as having equal access. For more granular control, you can implement per-tool authorization based on token claims:

server.tool("delete_record", { id: z.string() }, async (args, extra) => {
  // Check if this client has delete permission
  const user = extra.requestContext?.user;
  if (!user?.permissions?.includes("write")) {
    throw new Error("Insufficient permissions for delete_record");
  }
  // Proceed with deletion
});

Securing Credentials in Client Configurations#

When configuring MCP servers in Claude Desktop or other clients, credentials should be provided through environment variables — never hardcoded in the config file:

{
  "mcpServers": {
    "my-api": {
      "command": "npx",
      "args": ["my-mcp-server"],
      "env": {
        "API_KEY": "${MY_API_KEY}"
      }
    }
  }
}

For remote servers accessed over HTTP/SSE, the API key or token should be stored in the client's environment and injected at connection time, not stored in any config file that might be version-controlled.

MCP Authentication Security Checklist#

Before deploying a remote MCP server, verify:

• All endpoints require authentication — no unauthenticated access to any MCP route
• API keys are at least 32 bytes of cryptographically random data
• Credentials are stored as environment variables, not in code or config files
• HTTPS is enforced for all HTTP/SSE transport endpoints
• Rate limiting is applied per API key to prevent abuse
• Failed authentication attempts are logged with IP and timestamp
• API keys can be rotated without downtime (avoid single hard-coded keys)
• If using OAuth 2.1, PKCE is required for the authorization code flow

See the MCP server security tutorial for a complete implementation guide covering these topics plus input validation and audit logging.

Authentication for Multi-Tenant Servers#

If your MCP server serves multiple users or organizations, authentication must also drive tenant isolation. Each API key should map to a specific tenant context, and every database query and file operation must be scoped to that tenant:

// Middleware extracts tenant from validated token
function tenantMiddleware(req: express.Request, res: express.Response, next: express.NextFunction) {
  const apiKey = req.headers.authorization?.replace("Bearer ", "");
  const tenant = lookupTenantByApiKey(apiKey); // Your lookup logic

  if (!tenant) {
    res.status(403).json({ error: "Unknown API key" });
    return;
  }

  (req as any).tenantId = tenant.id;
  next();
}

All tool implementations then use tenantId to scope their queries. Never mix data across tenants.

Related Terms#

Browse all terms in the AI agent glossary.

• MCP Transport — the communication layer where authentication is applied
• MCP Server — the server that enforces authentication
• MCP Client — the client that supplies credentials
• Agent Sandbox — broader isolation strategy for AI tool execution
• Model Context Protocol — the full protocol specification

Frequently Asked Questions#

Do local stdio MCP servers need authentication?

No. Stdio servers run as subprocesses of the client, inheriting the client user's OS permissions. Only that specific client process can communicate with the server. If you are concerned about the security boundary between the client and server processes — for example, if the server runs tools that could escalate privileges — consider running the server subprocess under a restricted OS user account using sudo -u restricted-user or a container.

Can I use an existing identity provider for MCP OAuth?

Yes, and this is the recommended approach. Services like Auth0, Clerk, Okta, and Supabase Auth implement OAuth 2.1 authorization servers. You configure your MCP server to accept tokens from your identity provider by validating the token's signature against the provider's public keys (available at their JWKS endpoint). The MCP client performs the OAuth flow against your identity provider, receives a token, and sends that token to your MCP server. Your server validates but does not issue tokens.

What happens if an API key is compromised?

Revoke it immediately and issue a new one. This is why your authentication layer should support per-client API keys rather than a single shared secret. With per-client keys, you can revoke one compromised key without affecting other clients. Implement a key management API or admin interface that lets you list active keys, see their last-used timestamps, and revoke individual keys without restarting the server.

See also: comparisons for practical examples.