Securing the Model Context Protocol (MCP): Building a Production-Ready, OAuth 2.1 Authenticated Server over HTTP

#javascript #webdev #ai #security

As engineering organizations connect Large Language Models (LLMs) to sensitive business databases and internal developer systems, secure communication boundaries are no longer optional.

While running Model Context Protocol (MCP) servers locally using standard input/output (stdio) depends on local process boundaries, deploying remote MCP services over HTTP transport exposes deep security risks. Relying on static, long-lived API keys creates a single point of failure and does not support multi-user data scoping.

To address this challenge, we built and open-sourced Coreframe Labs' Secure MCP Template, implementing a production-ready, spec-compliant OAuth 2.1 authorization layer on top of a Node.js/TypeScript server over Server-Sent Events (SSE).

The Core Problem: Why API Keys Fail in AI Agent Environments

In typical application architectures, an API key is granted to an external system, which then has full access to the target API. However, AI agents sit at a unique intersection: they serve multiple clients (such as Claude Desktop or Cursor), act on behalf of diverse enterprise users, and execute operations dynamically.

Passing static API keys through locally installed desktop agents creates significant risk:

Standardizing authorization via OAuth 2.1 solves these issues natively. It enforces Proof Key for Code Exchange (PKCE) for all clients, eliminates insecure implicit flows, and requires exact matching on redirect URIs.

Architectural Breakdown: The Secure Remote Handshake

Our open-source implementation follows the standard OAuth 2.1 authorization lifecycle for remote, HTTP-based MCP servers:[ MCP Client / Host ] ───────── (1) GET /api/tools (No Token) ────────► [ Remote MCP Server ]◄── (2) 401 Unauthorized (PRM Pointer) ───

[ MCP Client / Host ] ─── (3) Fetch Protected Resource Metadata ────────► [ OAuth Provider ]◄────── (4) Auth Endpoint & Scopes ─────────

[ MCP Client / Host ] ────────── (5) Authorize with PKCE (S256) ────────► [ OAuth Provider ]◄─────────── (6) Scoped Bearer Token ──────────────

[ MCP Client / Host ] ────────── (7) GET /api/tools (With Token) ────────► [ Remote MCP Server ]

Plain textANTLR4BashCC#CSSCoffeeScriptCMakeDartDjangoDockerEJSErlangGitGoGraphQLGroovyHTMLJavaJavaScriptJSONJSXKotlinLaTeXLessLuaMakefileMarkdownMATLABMarkupObjective-CPerlPHPPowerShell.propertiesProtocol BuffersPythonRRubySass (Sass)Sass (Scss)SchemeSQLShellSwiftSVGTSXTypeScriptWebAssemblyYAMLXML### 1. The Initial Handshake & Discovery When an unauthorized client attempts to access our exposed tools or resources, the server rejects the request with an HTTP `401 Unauthorized` status. It attaches a `WWW-Authenticate` header containing a secure pointer to our Protected Resource Metadata (PRM) document [cite: 3, 4]:http HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="mcp", resource_metadata="[https://mcp-auth-demo-production-d421.up.railway.app/.well-known/oauth-protected-resource](https://mcp-auth-demo-production-d421.up.railway.app/.well-known/oauth-protected-resource)"`

The client fetches this document to learn the authorization server's URL, supported token endpoints, and the specific permissions (scopes) required.

2. Client ID Metadata Documents (CIMD)

To prevent unauthorized clients from dynamically registering with our enterprise server, our implementation validates the client's identity using Client ID Metadata Documents (CIMD). This configuration replaces fragile, manually configured client secrets with dynamic, cryptographically verifiable documents hosted securely on the client's domain.

3. Constant-Time Cryptographic Verification

A common vulnerability in custom token validation logic is the use of non-constant-time string comparisons. Standard string operators (==) return false immediately upon detecting a character mismatch, exposing the system to timing-based side-channel attacks.

Our template mitigates this risk by enforcing constant-time comparisons across all token verification routes:

TypeScript

Plain textANTLR4BashCC#CSSCoffeeScriptCMakeDartDjangoDockerEJSErlangGitGoGraphQLGroovyHTMLJavaJavaScriptJSONJSXKotlinLaTeXLessLuaMakefileMarkdownMATLABMarkupObjective-CPerlPHPPowerShell.propertiesProtocol BuffersPythonRRubySass (Sass)Sass (Scss)SchemeSQLShellSwiftSVGTSXTypeScriptWebAssemblyYAMLXML import { timingSafeEqual } from 'crypto'; export function verifyAccessToken(suppliedToken: string, expectedToken: string): boolean { const suppliedBuf = Buffer.from(suppliedToken); const expectedBuf = Buffer.from(expectedToken); if (suppliedBuf.length !== expectedBuf.length) { return false; } return timingSafeEqual(suppliedBuf, expectedBuf); }

Try It Yourself: Deployment & Live Demo

We have deployed the live interactive demo on Railway to demonstrate this authorization handshake in real-time.

🎮 Live Interactive Demo: https://mcp-auth-demo-production-d421.up.railway.app/demo/
📦 GitHub Repository: https://github.com/CoreframeLabs/mcp-auth-template

To spin up the template locally, clone our repository and configure your environment variables:

Bash

Join the Discussion

Implementing security layers for remote AI agents is a rapidly evolving space.

How is your engineering team currently securing external integrations? Are you moving toward OAuth 2.1-compliant architectures, or relying on network-isolated VPC environments?

Share your architectural designs, feedback, or any security bottlenecks you've encountered in the comments below!