01Modelo de roles: el servidor MCP como resource server
Desde la revisión 2025-06-18, un servidor MCP protegido actúa como resource server OAuth 2.1: recibe y valida access tokens, pero no los emite él mismo; el cliente MCP actúa como cliente OAuth en nombre del usuario. El authorization server es un rol separado: puede alojarse junto con el resource server, pero su implementación queda fuera del alcance de la especificación. No siempre fue así: la revisión 2025-03-26 trataba de facto al servidor MCP como authorization server y resource server a la vez, con endpoints por defecto /authorize, /token y /register directamente en el servidor MCP. La separación formal descarga a los operadores de servidores y permite usar proveedores de identidad consolidados en lugar de una emisión de tokens de fabricación propia.
02Cadena de discovery: RFC 9728 y RFC 8414
El cliente localiza el authorization server competente en tiempo de ejecución en lugar de por configuración: a una petición sin token válido, el servidor MCP responde con 401 Unauthorized y remite, mediante la cabecera WWW-Authenticate, a sus Protected Resource Metadata (RFC 9728), un documento obligatorio cuyo campo authorization_servers nombra al menos un authorization server. Desde ahí, el cliente carga los Authorization Server Metadata según RFC 8414 (/.well-known/oauth-authorization-server) con los endpoints de autorización, de token y de registro; solo entonces comienza el flujo OAuth 2.1 propiamente dicho. Esta discovery en tiempo de ejecución sustituye a la configuración codificada en duro, algo decisivo para agentes a los que las herramientas se les asignan solo en tiempo de ejecución. La revisión 2025-11-25 añade OpenID Connect Discovery y un fallback .well-known sin cabecera; la revisión 2026-07-28 añade la validación del issuer según RFC 9207 contra ataques de tipo mix-up.
03Registro de clientes: RFC 7591 y CIMD
Como clientes MCP cualesquiera se encuentran con servidores cualesquiera, el registro manual de clientes no escala. Por eso, la revisión 2025-06-18 recomienda (SHOULD) el Dynamic Client Registration según RFC 7591: el cliente se registra a sí mismo en el endpoint de registro y recibe su propio client_id; en la práctica, casi siempre como public client sin client secret; las alternativas son un client ID preconfigurado o la introducción manual. La revisión 2026-07-28, sin embargo, declara el DCR deprecated y apuesta por los Client ID Metadata Documents (CIMD) introducidos con la revisión 2025-11-25: identidades de cliente basadas en URL. Al mismo tiempo aclara que las client credentials almacenadas están vinculadas al authorization server emisor y no deben reutilizarse a través de los límites entre servidores. El DCR sigue funcionando de forma transitoria por razones de compatibilidad; las nuevas implementaciones deberían conocer ambas vías.
04Reglas básicas de OAuth 2.1: PKCE, cabeceras, vidas cortas
OAuth 2.1 elimina los legados inseguros de OAuth 2.0: desaparecen el implicit grant y el password grant, las redirect URIs solo se comparan de forma exacta y PKCE es obligatorio: los clientes MCP DEBEN implementar PKCE, en la práctica con el método de challenge S256 en lugar de «plain». Los access tokens deben ir como bearer tokens en la cabecera Authorization de cada petición y nunca deben aparecer en la query string del URI; todos los endpoints del authorization server funcionan sobre HTTPS, y las redirect URIs se limitan a localhost o HTTPS. Los refresh tokens de public clients deben ser, según OAuth 2.1, sender-constrained o tokens de un solo uso con rotación. Las recomendaciones prácticas habituales añaden access tokens de vida corta, de pocos minutos, así como detección de reutilización que, al reutilizarse un refresh token antiguo, revoca toda la familia de tokens.
05Vinculación de audiencia (RFC 8707) y prohibición del token passthrough
Un token debe emitirse para exactamente un servidor MCP: los clientes DEBEN enviar el parámetro resource según RFC 8707 en las peticiones de autorización y de token, indicando en él el URI canónico del servidor de destino; el servidor DEBE comprobar que es la intended audience y rechazar con 401 los tokens ajenos o caducados. Igual de estricta es la prohibición del passthrough: un servidor MCP NO DEBE reenviar el token recibido del cliente a APIs situadas aguas abajo, sino actuar allí como cliente OAuth propio con su propio token. De lo contrario amenaza el problema del confused deputy: el servidor actúa como apoderado confundido con privilegios ajenos, y el rate limiting, la monitorización y la pista de auditoría de la API aguas abajo quedan en nada. Los servidores proxy con client ID estático DEBEN además recabar un consentimiento de usuario propio para cada cliente registrado dinámicamente, porque de lo contrario las cookies de consentimiento reutilizadas dirigen authorization codes a los atacantes.
06MCP07 en la práctica: hallazgos y controles
El OWASP MCP Top 10 (versión v0.1, beta; no es un estándar finalizado) recoge este ámbito como MCP07 «Insufficient Authentication & Authorization». El hallazgo en la práctica es desalentador: Trend Micro encontró en 2025 un total de 492 servidores MCP expuestos en Internet sin autenticación ni cifrado del transporte, la auditoría de Astrix contó un 53 por ciento de claves API estáticas frente a solo un 8,5 por ciento de OAuth, y la CVE-2025-6514 en el paquete npm mcp-remote (CVSS 9,6) demostró que unos campos de discovery OAuth manipulados bastan para desencadenar ejecución de código. Los controles eficaces parten de la especificación: OAuth 2.1 con PKCE y un authorization server separado, tokens de vida corta y vinculados a la audiencia en lugar de passthrough (con token exchange según RFC 8693 en las llamadas aguas arriba), consentimiento por cliente en los proxies y el servidor MCP como non-human identity propia en el IAM. Dos preguntas de control para auditoría interna y dirección: ¿hay un token passthrough en algún punto de la cadena, y cuánto vive un token de agente?
