OAuth 2.1 para MCP: cómo proteger servidores remotos sin romper los clientes

Un servidor MCP remoto que lee documentos o ejecuta tools no puede confiar en que el cliente sea conocido. OAuth 2.1 no es un botón de login: es el contrato que descubre identidad, limita scopes y permite validar cada llamada sin convertir la autorización en un prompt.

OAuth 2.1 para MCP es el mecanismo para que un cliente obtenga un token con permiso limitado y un servidor MCP remoto compruebe ese token antes de exponer tools, recursos o acciones. En MCP, el servidor protegido es un resource server; el host del agente es el OAuth client; y tu proveedor de identidad emite los access tokens.

La propiedad evergreen es que el patrón no depende de un host concreto. Cambiarán SDKs y pantallas de consentimiento; seguirán siendo necesarios un resource identifier estable, metadata verificable, PKCE, token validation y una política de autorización que no viva dentro del modelo.

Protected Resource Metadata: la pieza que suele faltar

Protected Resource Metadata es un JSON servido por el resource server, no por el proveedor de login. Según RFC 9728 y MCP, publica el identificador del recurso y los authorization servers autorizados. En una ruta MCP como `https://mcp.acme.test/remote`, el cliente puede buscar `https://mcp.acme.test/.well-known/oauth-protected-resource/remote` o seguir el `resource_metadata` del challenge, que debe tener prioridad.

Implementación Node: challenge, metadata y guard de token

El SDK MCP puede encargarse del transporte y del registro de tools, pero el borde HTTP debe seguir devolver metadata y rechazar tokens inválidos antes de llegar al modelo o a los sistemas internos. Este ejemplo usa Express y `jose` para mostrar el contrato; adapta los endpoints y claims a tu proveedor de identidad. En producción, cachea JWKS respetando sus cabeceras y mantén las URLs de issuer y audiencia en configuración revisada, no en input del usuario.

<div style="margin:28px 0;border:1px solid #dbe3ef;border-radius:12px;overflow:hidden;background:#0f172a;"> <div style="padding:10px 14px;background:#111827;color:#cbd5e1;font:13px Consolas,monospace;">auth-boundary.mjs</div> <pre style="margin:0;padding:18px;overflow:auto;color:#e5e7eb;font:13px/1.55 Consolas,monospace;"><code>import express from "express"; import { createRemoteJWKSet, jwtVerify } from "jose"; const app = express(); const resource = "https://mcp.example.com/mcp"; const issuer = "https://login.example.com"; const jwks = createRemoteJWKSet(new URL(`${issuer}/.well-known/jwks.json`)); app.get("/.well-known/oauth-protected-resource/mcp", (_req, res) =&gt; { res.type("application/json").send({ resource, authorization_servers: [issuer], scopes_supported: ["issues:read", "issues:write"], }); }); async function requireScope(req, res, next) { const token = req.get("authorization")?.replace(/^Bearer\s+/i, ""); if (!token) { res.set("WWW-Authenticate", `Bearer resource_metadata="${resource.replace("/mcp", "/.well-known/oauth-protected-resource/mcp")}", scope="issues:read"`); return res.sendStatus(401); } try { const { payload } = await jwtVerify(token, jwks, { issuer, audience: resource }); const scopes = String(payload.scope || "").split(" "); if (!scopes.includes("issues:read")) return res.sendStatus(403); req.actor = { subject: payload.sub, tenant: payload.tenant_id }; return next(); } catch { return res.sendStatus(401); } } app.post("/mcp", requireScope, mcpHttpHandler);</code></pre> </div>

No copies este fragmento sin decidir si tu access token es JWT, opaco o ambos. Un token opaco normalmente se valida por introspección contra el authorization server; un JWT se valida contra claves públicas confiables. En ambos casos, la audiencia debe ser el resource identifier de tu MCP, no el nombre genérico de tu producto.

No prometas soporte universal antes de probar hosts reales. Algunos clientes aún llegarán con capacidades antiguas. Publica claramente qué versiones, mecanismo de registro y scopes admites; ofrece el fallback mínimo sin bajar la validación del token por «compatibilidad».

Errores que rompen autorización MCP

• Proteger solo la pantalla de consentimiento y dejar `/mcp` sin validar `Authorization` en cada request.
• Aceptar cualquier issuer que aparezca en un JWT o construir el JWKS URL con una claim no confiable.
• Comprobar firma y expiración, pero omitir audiencia, scopes, tenant y autorización del recurso concreto.
• Usar una API key global como identidad del usuario y registrar todas las acciones como si las hiciera el servidor.
• Devolver access tokens, authorization codes, cabeceras Bearer o datos de consentimiento en logs de trazas.
• Entregar `write` al conectar el servidor aunque el usuario solo quiera explorar datos de lectura.
• Confiar en que el modelo no invocará una tool peligrosa si el system prompt dice que tenga cuidado.