Autenticación MCP: guía de seguridad OAuth

Última actualización: 15 de octubre, 2026

¿Qué es la autenticación MCP? Es la forma en que un cliente MCP demuestra que puede llamar a un servidor MCP. En los transportes HTTP, la especificación actual la basa en OAuth 2.1: el servidor actúa como servidor de recursos y un servidor de autorización distinto emite los tokens. Los servidores stdio locales omiten OAuth y leen las credenciales del entorno.

TL;DR: puntos clave

• La especificación MCP 2026-07-28 exige que los servidores protegidos publiquen metadatos RFC 9728 y que los clientes envíen el parámetro resource de la RFC 8707 en 2 solicitudes: autorización y token (especificación MCP).
• El token passthrough está prohibido: la especificación nombra 2 modos de fallo, la validación de audiencia fallida y el passthrough (buenas prácticas de seguridad de MCP).
• Un fallo en el cliente OAuth del SDK de Python de MCP afectó a las versiones 1.9.1 a 2.1.1 y se corrigió en la 1.30.0 y la 2.2.0, según Cycode (2026).
• Se puntúa 7,5 (alta) para los 2 proveedores máquina a máquina y 6,5 para el interactivo, según The Hacker News (2026).

Autenticación MCP de un vistazo

Cómo funciona la autenticación MCP

La autenticación MCP sigue un único patrón. El cliente llama al servidor sin token y recibe un desafío 401. Luego descubre el servidor de autorización, obtiene un token con un flujo de código de autorización con PKCE y lo envía en cada solicitud. Según la especificación MCP (2026-07-28), el servidor es un servidor de recursos OAuth 2.1. OAuth 2.1 sigue siendo un borrador del IETF.

Para más amenazas lee MCP Security 101 y, para lo básico, Qué es el Model Context Protocol.

Cómo hemos elaborado esta guía

Leímos las páginas de autorización de MCP 2026-07-28, las buenas prácticas de seguridad, el análisis de Cycode, la noticia de The Hacker News y las notas del SDK. No ejecutamos el SDK y no pudimos abrir la página del aviso en GitHub, así que los datos del aviso proceden de los dos informes.

Descubrimiento del servidor de autorización en MCP

El cliente encuentra el servidor de autorización en dos saltos. El servidor MCP lo anuncia en los metadatos del recurso protegido y luego el cliente lee los del propio servidor de autorización. Ambos son no fiables hasta validarlos.

Según las reglas de descubrimiento, los servidores anuncian los metadatos del recurso mediante una URL resource_metadata en la cabecera WWW-Authenticate del 401, o en una URI well-known como /.well-known/oauth-protected-resource. El documento debe listar authorization_servers. Los clientes admiten ambas vías.

Para los metadatos del servidor de autorización, los clientes prueban primero la URI de la RFC 8414 y después los endpoints de OpenID Connect Discovery. El issuer del documento debe ser idéntico al emisor usado para construir la URL, o el cliente no debe usarlo. El ejemplo de la propia especificación es un documento obtenido de attacker.example que declara https://honest.example, y que debe rechazarse.

Registro de clientes, PKCE e indicadores de recurso

Las reglas de registro de clientes prefieren las credenciales preregistradas, luego los Client ID Metadata Documents y después el Dynamic Client Registration. PKCE con S256 y el parámetro resource son obligatorios.

Los clientes deben asociar las credenciales guardadas al issuer del servidor de autorización y no reutilizarlas con otro. En PKCE, si code_challenge_methods_supported no aparece en los metadatos, el cliente debe negarse a continuar. El valor de resource es la URI canónica del servidor, como https://mcp.example.com/mcp.

PKCE por sí solo no frena un ataque de mix-up, señalan las buenas prácticas de seguridad, porque el cliente envía el code_verifier al token endpoint del atacante. De ahí la comprobación exacta del emisor en la respuesta de autorización.

Vinculación de audiencia, token passthrough y el confused deputy

Un servidor MCP debe aceptar solo tokens emitidos para él y nunca reenviar el token que recibió a una API ascendente. Si llama a un servicio de terceros, necesita un token distinto del servidor de autorización de ese servicio.

Las buenas prácticas definen el token passthrough como aceptar el token de un cliente sin comprobar que se emitió para el servidor y pasarlo después a otro servicio. Entre los riesgos citan la elusión de controles y los huecos de auditoría. Los servidores deben rechazar los tokens que no los incluyan como audiencia, según las consideraciones de seguridad de la autorización.

El problema del confused deputy

Afecta a los proxies MCP que dan acceso a una API de terceros con un único client ID estático. Según las buenas prácticas, resulta posible cuando se combinan el dynamic client registration, una cookie de consentimiento y la falta de consentimiento por cliente en el proxy. La mitigación es el consentimiento por cliente.

Scopes, step-up authorization y 401 frente a 403

Los scopes deciden qué puede hacer un token válido. Los servidores desafían con los scopes que necesita la operación actual, los clientes empiezan por el mínimo y un 403 con insufficient_scope activa la step-up authorization.

En el step-up, el cliente solicita la unión de sus scopes anteriores y los nuevos desafiados. Las buenas prácticas advierten contra publicar cada scope en scopes_supported y contra los comodines como * o full-access.

Servidores stdio: credenciales de entorno en lugar de OAuth

La especificación dice que las implementaciones stdio no deben seguir la especificación de autorización y deben obtener las credenciales del entorno. No hay audiencia, descubrimiento ni consentimiento, así que la credencial del entorno es justo lo que el servidor puede usar. Da a cada servidor local su propia credencial acotada, no una clave de administrador personal. Las buenas prácticas advierten de que los servidores locales se ejecutan con los privilegios del cliente, así que aísla el proceso en un sandbox.

El fallo de septiembre de 2026 en el SDK de Python de MCP

En septiembre de 2026, los mantenedores del SDK oficial de Python de MCP publicaron el aviso GHSA-qx49-fqc8-xw99 por un fallo OAuth del lado cliente. Según Cycode (2026), un servidor MCP malicioso podía desviar el flujo OAuth del SDK para que el client secret, el código y el verificador PKCE llegaran al atacante.

Qué se vio afectado

Cycode informa de que se vieron afectadas las versiones 1.9.1 a 2.1.1 del SDK, en tres proveedores. The Hacker News añade el RFC7523OAuthClientProvider obsoleto de la rama 1.x. No se ven afectados los servidores del SDK, los clientes stdio ni los clientes que adjuntan sus propios tokens. No se había asignado ningún CVE el 29 de septiembre, según The Hacker News (2026).

Cómo funcionaba el ataque

Cycode describe esta cadena. El servidor malicioso responde con un HTTP 404 a la solicitud de descubrimiento moderna, lo que lleva al SDK a una ruta alternativa sin comprobación del emisor. Los metadatos apuntaban el inicio de sesión al proveedor real y el token endpoint al atacante. El usuario veía un login genuino y el SDK enviaba el código, el client secret y el verificador al atacante.

Cycode lo califica de toma de control total de la cuenta y sostiene que el 6,5 infravalora el riesgo del proveedor interactivo. Son opiniones del investigador. Según The Hacker News, ni el aviso ni Cycode informan de ataques.

La corrección y qué hacer

Las versiones corregidas son la 1.30.0 y la 2.2.0. Las notas de versión dicen, en su redacción original, «Authorization server metadata whose issuer doesn't match the server it was fetched for is now rejected». Añaden que los registros de cliente se recuerdan por emisor (notas de versión del SDK). The Hacker News señala que llegaron el 7 de septiembre como cambios de comportamiento y que el aviso salió el 28. Remediación indicada:

1. Actualiza a la 1.30.0 o la 2.2.0.
2. Pasa issuer= en los 2 proveedores máquina a máquina: actualizar solo no cambia nada.
3. Borra una vez los registros de cliente almacenados para recrearlos vinculados al emisor.
4. Si un cliente pudo conectar con un servidor no fiable, rota su secreto y revoca sus tokens.

Qué implica

Es un hueco de validación del lado cliente que la especificación actual prohíbe: el texto 2026-07-28 manda rechazar metadatos con un emisor que no coincide. Una regla solo ayuda si tu biblioteca la aplica. Trata como no fiables las URL de descubrimiento, conecta los flujos OAuth solo con servidores revisados e inventaría las aplicaciones que incorporan el SDK.

Errores habituales de autenticación MCP

Errores contra los que advierte la propia especificación:

Checklist de producción: protege un servidor MCP con OAuth en 7 pasos

Vale para un servidor remoto con Streamable HTTP, según la especificación 2026-07-28.

Cómo proteger un servidor MCP con OAuth

1. Elige el transporte. OAuth en HTTP, credenciales de entorno acotadas en stdio.
2. Selecciona un servidor de autorización conforme. Debe publicar metadatos RFC 8414 u OpenID Connect con code_challenge_methods_supported.
3. Publica los metadatos del recurso protegido. Sirve un documento RFC 9728 con authorization_servers y devuelve 401 con resource_metadata en WWW-Authenticate.
4. Valida cada token. Comprueba firma, caducidad y que tu URI canónica esté en la audiencia.
5. Define scopes mínimos. Empieza con scopes de lectura y devuelve 403 con insufficient_scope cuando una herramienta necesite más.
6. No reenvíes nunca tokens. Usa una credencial distinta para las APIs ascendentes.
7. Monitoriza, rota y prueba. Emite tokens de vida corta, registra las elevaciones de scope con IDs de correlación y prueba los clientes con emisores que no coincidan.

Seguridad y gobernanza: lo que OAuth no cubre

OAuth dice quién llama y qué scopes tiene el token, no si un agente debe hacer una llamada concreta. Cuatro riesgos rodean una configuración correcta: robo de tokens, scopes excesivos, prompt injection y servidores en la sombra, recogidos en el OWASP MCP Top 10 (beta) como MCP01, MCP02, MCP06 y MCP09.

Robo de tokens

Según las consideraciones de seguridad de la autorización, quien obtenga tokens guardados por el cliente, o en logs del servidor, puede hacer solicitudes que parecen legítimas. La especificación indica que los servidores de autorización deben emitir tokens de vida corta.

Scopes excesivos

Un token con files:* o admin:* permite encadenar herramientas a quien lo tenga, y las buenas prácticas citan un mayor radio de impacto. Nuestra guía sobre excessive agency explica por qué el mínimo privilegio debe abarcar herramientas además de tokens.

Prompt injection que gobierna llamadas autenticadas

Un token válido autoriza lo que decida el agente, así que un texto inyectado puede dirigir una llamada con credenciales correctas. OWASP describe MCP06 como una inyección clásica en la que «the 'interpreter' is the model and the 'payload' is text». Nuestra guía sobre prompt injection en MCP cubre patrones y defensas.

Servidores MCP en la sombra

OWASP describe los servidores en la sombra como despliegues no aprobados fuera de la gobernanza formal. No puedes aplicar reglas OAuth a un servidor cuya existencia ignoras.

Cómo aborda NeuralTrust estos riesgos

Estos controles conviven con tu OAuth. Agent Gateway (TrustGate) se sitúa entre agentes, flujos, modelos y herramientas MCP y aplica permisos y límites por agente, así que un token válido no implica uso ilimitado de herramientas. Ofrece más de 200 servidores MCP prediseñados. Agent Runtime Security (TrustGuard) detecta prompt injection y fuga de datos en tiempo de ejecución. Agent Posture Management (TrustLens) inventaría agentes y sus conexiones, una base para detectar servidores no aprobados. AI Red Teaming (TrustTest) prueba los agentes antes del lanzamiento. Juntos forman el Runtime Security Mesh.

Qué enfoque de autenticación MCP elegir

Adapta el enfoque a quién llama al servidor. Las herramientas locales de un solo usuario pueden usar credenciales de entorno, mientras que los servidores remotos y multiusuario necesitan OAuth con validación de audiencia y scopes acotados.

Conclusión

La autenticación MCP se reduce a seguir la especificación al pie de la letra: publicar metadatos del recurso protegido, vincular los tokens a una audiencia, enviar el parámetro resource, exigir PKCE y no reenviar nunca un token. El fallo de septiembre muestra que los clientes también deben comprobar el emisor. Mantén los scopes al mínimo, rota los secretos y controla lo que puede hacer un agente autenticado, porque un token válido dice quién llama, no si la llamada es sensata.

Protege tus servidores MCP en producción con NeuralTrust

Aplica permisos por agente, detección en tiempo de ejecución y un inventario de conexiones en cada servidor MCP.

Comparativas relacionadas

• Qué es un servidor MCP
• Best MCP Gateways
• MCP Prompt Injection
• MCP Security 101

Preguntas frecuentes sobre autenticación MCP

1. ¿Qué es la autenticación MCP?

La autenticación MCP es cómo un cliente MCP demuestra que puede acceder a un servidor MCP. En HTTP se basa en OAuth 2.1: el servidor es un servidor de recursos, un servidor de autorización emite los tokens y el cliente los envía en cada solicitud. Los servidores stdio usan credenciales de entorno.

2. ¿Usa MCP OAuth 2.1?

Sí, en transportes HTTP. La especificación 2026-07-28 se apoya en el borrador de OAuth 2.1 del IETF y en las RFC 9728, 8414, 8707 y 9207. La autorización es opcional, pero las implementaciones HTTP deben ajustarse.

3. ¿Usan OAuth los servidores MCP stdio?

No. La especificación dice que las implementaciones stdio no deben seguir la de autorización y deben obtener las credenciales del entorno. Da a cada servidor una credencial acotada.

4. ¿Qué es el token passthrough y por qué está prohibido?

El token passthrough es que un servidor MCP acepte el token de un cliente sin comprobar que se emitió para él y lo reenvíe a otro servicio. La especificación lo prohíbe porque salta controles y enturbia la auditoría.

5. ¿Sigo necesitando Dynamic Client Registration?

No en trabajos nuevos. La especificación 2026-07-28 lo declara obsoleto y lo mantiene solo para servidores de autorización sin soporte de Client ID Metadata Documents.

6. ¿Fue vulnerable el SDK de Python de MCP en septiembre de 2026?

Su cliente OAuth sí. Según Cycode, las versiones 1.9.1 a 2.1.1 podían enviar el client secret, el código y el verificador PKCE a un token endpoint elegido por el atacante. Las correcciones son la 1.30.0 y la 2.2.0. The Hacker News no informa de ataques.

Sobre el autor

Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización para LLM. Se especializa en búsqueda con IA, estrategia de contenidos y SEM. Conecta en LinkedIn.

NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Reconocida como Pioneer en el Gartner Emerging Market Quadrant for AI Application Security 2026, destacada en cuatro informes Gartner Hype Cycle en 2026 y presente en el Gartner Market Guide for Guardian Agents 2026, el Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.

Fuentes

1. Model Context Protocol, «Authorization», revisión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
2. Model Context Protocol, «Authorization Server Discovery», revisión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery
3. Model Context Protocol, «Client Registration», revisión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration
4. Model Context Protocol, «Authorization Security Considerations», revisión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
5. Model Context Protocol, «Security Best Practices»: https://modelcontextprotocol.io/specification/latest/basic/security_best_practices
6. Cycode, «Cycode Uncovers Account Takeover in Anthropic's MCP Python SDK», 28 de septiembre de 2026 (actualizado el 29): https://cycode.com/blog/mcp-python-sdk-oauth-account-takeover/
7. The Hacker News, noticia sobre el fallo OAuth del SDK de Python de MCP (GHSA-qx49-fqc8-xw99), 29 de septiembre de 2026: https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html
8. Notas de versión v1.30.0 del SDK de Python de MCP, reflejadas por newreleases.io: https://newreleases.io/project/github/modelcontextprotocol/python-sdk/release/v1.30.0
9. OWASP, «MCP Top 10» (beta): https://owasp.org/www-project-mcp-top-10/