MCP Authentication Guide

Learn how to implement authentication in MCP servers — JWT tokens, API keys, OAuth 2.1, and how mcp-framework and the official SDK handle auth.

title: "MCP Authentication Guide" description: "Learn how to implement authentication in MCP servers — JWT tokens, API keys, OAuth 2.1, and how mcp-framework and the official SDK handle auth." order: 5 keywords:

• MCP authentication
• MCP auth
• MCP JWT
• MCP API key
• MCP OAuth
• MCP OAuth 2.1
• MCP security
• MCP server authentication
• model context protocol auth date: "2026-04-01"

Why Authentication Matters for MCP

When an MCP server runs over HTTP, it is exposed to the network — and potentially the internet. Without authentication, anyone who can reach the server's endpoint can invoke its tools, including tools that modify data, access sensitive information, or trigger external actions.

Authentication is critical for:

• Preventing unauthorized access to server capabilities
• Identifying clients for audit logging and access control
• Enforcing per-client permissions on which tools and resources are available
• Rate limiting and abuse prevention
• Multi-tenant deployments where different clients have different access levels

Authentication Methods

API Key Authentication

API key authentication is the simplest method. The client includes a pre-shared key in the request headers, and the server validates it before processing any requests.

Implementing API Key Auth

With mcp-framework, you can add API key authentication middleware to your HTTP transport:

import { MCPServer } from "mcp-framework";

const server = new MCPServer({
  transport: {
    type: "httpStream",
    options: {
      port: 3000,
      endpoint: "/mcp",
      middleware: (req, res, next) => {
        const apiKey = req.headers["x-api-key"];
        if (apiKey !== process.env.MCP_API_KEY) {
          res.status(401).json({ error: "Unauthorized" });
          return;
        }
        next();
      },
    },
  },
});

JWT Authentication

JSON Web Tokens (JWT) provide stateless authentication with built-in expiration and claims. The client obtains a JWT from an identity provider and includes it in the Authorization header of each request.

How JWT Works with MCP

1. Client authenticates with an identity provider and receives a JWT
2. Client includes the JWT in the Authorization: Bearer <token> header
3. Server validates the JWT signature, expiration, and claims
4. Server extracts client identity and permissions from the token claims
5. Server processes the MCP request based on the client's permissions

import jwt from "jsonwebtoken";

function validateJWT(req, res, next) {
  const token = req.headers.authorization?.replace("Bearer ", "");
  if (!token) {
    return res.status(401).json({ error: "No token provided" });
  }

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.clientId = payload.sub;
    req.scopes = payload.scopes;
    next();
  } catch (err) {
    return res.status(401).json({ error: "Invalid token" });
  }
}

JWT Claims for MCP

When using JWT with MCP servers, consider including these claims:

OAuth 2.1 Authentication

OAuth 2.1 is the MCP specification's recommended authentication mechanism for HTTP transports. It provides a standardized flow for third-party clients to obtain authorized access to MCP servers.

OAuth 2.1 Flow for MCP

1. Discovery — Client discovers the server's OAuth metadata at /.well-known/oauth-authorization-server
2. Authorization — Client redirects the user to the authorization endpoint
3. PKCE — Client uses Proof Key for Code Exchange (mandatory in OAuth 2.1)
4. Token exchange — Client exchanges the authorization code for access and refresh tokens
5. Authenticated requests — Client includes the access token in the Authorization header
6. Token refresh — Client uses the refresh token when the access token expires

Client                    Auth Server                MCP Server
  │                           │                          │
  ├─ GET /.well-known/oauth ─→│                          │
  │←─ OAuth metadata ─────────┤                          │
  │                           │                          │
  ├─ Authorization request ──→│                          │
  │←─ Authorization code ─────┤  (user approves)         │
  │                           │                          │
  ├─ Token exchange ─────────→│                          │
  │←─ Access + Refresh token ─┤                          │
  │                           │                          │
  ├─ MCP request + Bearer token ───────────────────────→ │
  │←─ MCP response ──────────────────────────────────────┤

Per-Tool Authorization

Beyond authenticating the client, MCP servers can implement per-tool authorization — restricting which tools each client is allowed to invoke.

const toolPermissions = {
  "read-only-client": ["query_database", "list_files"],
  "admin-client": ["query_database", "list_files", "delete_records", "modify_schema"],
};

function authorizeToolCall(clientId, toolName) {
  const allowed = toolPermissions[clientId] || [];
  return allowed.includes(toolName);
}

Environment Variable Patterns

For stdio-based servers, authentication to external services is typically handled through environment variables passed by the host:

{
  "mcpServers": {
    "github-server": {
      "command": "node",
      "args": ["github-mcp-server/dist/index.js"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx",
        "GITHUB_ORG": "my-organization"
      }
    }
  }
}

Security Checklist

Use this checklist when implementing authentication for your MCP server:

• Determine which transport(s) your server uses and their authentication needs
• For HTTP transports, choose an authentication method (API key, JWT, or OAuth 2.1)
• Implement TLS/HTTPS for all HTTP connections
• Validate all tokens and keys on every request
• Implement per-tool authorization for sensitive operations
• Set appropriate token expiration times
• Plan for credential rotation
• Log authentication events for auditing
• Test authentication failure paths
• Document authentication requirements for client developers