La autenticación es la capa de seguridad más crítica para los servidores MCP remotos. Aprende por qué OAuth 2.1 con OIDC es obligatorio, cómo la delegación de tokens previene el ataque del Diputado Confundido, y por qué el token passthrough es uno de los patrones más peligrosos en integraciones de IA.
La autenticación es el guardián que determina si las poderosas capacidades de un servidor MCP están disponibles para usuarios legítimos o para atacantes. Si falla, cualquier otro control de seguridad se vuelve irrelevante — un servidor MCP no autenticado o mal autenticado con acceso a correo electrónico, archivos y bases de datos es una vulnerabilidad crítica sin importar qué tan bien hayas reforzado todo lo demás.
La guía del Proyecto de Seguridad OWASP GenAI identifica la autenticación y autorización como uno de los ocho dominios de seguridad principales para servidores MCP, con requisitos específicos que van más allá de lo que la mayoría de los desarrolladores implementan por defecto. Este artículo explica por qué existen esos requisitos y cómo implementarlos correctamente.
Los servidores MCP enfrentan un panorama de autenticación más complejo que los servicios tradicionales porque median entre múltiples principales:
Cada una de estas relaciones requiere sus propios controles de autenticación y autorización. Una debilidad en cualquier eslabón puede ser explotada para eludir los demás.
Para servidores MCP remotos — aquellos accedidos a través de una red en lugar de mediante STDIO local o sockets Unix — la guía OWASP GenAI es inequívoca: OAuth 2.1 con OIDC es obligatorio, no opcional.
Este requisito existe porque:
OAuth 2.1 proporciona control de alcance explícito. Cada token de acceso declara exactamente qué recursos y acciones autoriza. Un servidor MCP puede verificar en el momento de la invocación de herramienta que el token presentado tiene el alcance específico necesario para esa acción — no solo que el usuario está autenticado, sino que está autorizado para esta operación específica.
OIDC proporciona identidad criptográfica. OpenID Connect agrega aserciones de identidad (el token ID) que el servidor MCP puede verificar sin hacer un viaje de ida y vuelta al proveedor de identidad. El servidor valida el iss (emisor), aud (audiencia), exp (expiración) y la firma en cada solicitud.
Los tokens OAuth 2.1 son de corta duración por diseño. La especificación moderna de OAuth (que consolida y reemplaza las mejores prácticas de OAuth 2.0) enfatiza tokens de acceso de corta duración que deben ser actualizados regularmente. Esto limita la ventana de daño si un token es comprometido.
No valides tokens solo al establecimiento de sesión. Valida en cada invocación de herramienta:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Nunca almacenes en caché los resultados de validación entre solicitudes. Un token que era válido al inicio de sesión puede ser revocado a mitad de sesión.
En entornos donde los clientes MCP cambian frecuentemente (por ejemplo, diferentes asistentes de IA conectándose al mismo servidor), las claves API estáticas o secretos precompartidos son insuficientes. Usa registro dinámico de clientes con OAuth 2.1 u OIDC para verificar la identidad del cliente en el momento de conexión. Las listas de permitidos, políticas de conexión codificadas o TLS mutuo (mTLS) son apropiadas para relaciones estáticas conocidas entre clientes y servidores específicos.
Comienza tu prueba gratuita hoy y ve resultados en días.
El Diputado Confundido es una vulnerabilidad de autorización clásica con una manifestación particularmente peligrosa en arquitecturas MCP. El ataque explota la ambigüedad de con qué autoridad está actuando un servidor MCP.
Considera este escenario:
Cuando Alice le pide al asistente de IA “resumir mi carpeta de proyecto”, el servidor usa el token de Alice para acceder a sus archivos — comportamiento correcto. Pero si un atacante engaña al servidor para hacer una solicitud usando sus propias credenciales de servicio (quizás a través de un ataque de envenenamiento de herramientas o inyección de prompt indirecta), los permisos elevados del servidor se usan para acceder a archivos que Alice no está autorizada a ver.
El servidor es el “diputado confundido” — ha sido engañado para usar su autoridad en nombre de alguien que no tiene esa autoridad, actuando como un proxy para escalada de privilegios.
Muchas implementaciones MCP reenvían el token del cliente a APIs descendentes por simplicidad. Esto parece intuitivo — el token del usuario representa los permisos del usuario, así que usarlo para todas las llamadas descendentes mantiene el control de acceso correcto.
El problema: las APIs descendentes que reconocen al servidor MCP como un intermediario de confianza pueden otorgar solicitudes usando el nivel de identidad del servidor, no el nivel del token de usuario reenviado. Y si el servidor MCP alguna vez actúa por iniciativa propia — a través de toma de decisiones de IA que el usuario no solicitó explícitamente — puede usar sus propias credenciales en lugar del token del usuario.
Reenviar tokens de usuario también:
En lugar de reenviar tokens de cliente, el servidor MCP debería obtener sus propios tokens para acceso a servicios descendentes usando el flujo On-Behalf-Of (OBO) de OAuth:
Usuario se autentica con cliente MCP → cliente obtiene token de acceso de usuario
Cliente MCP presenta token de usuario al servidor MCP
Servidor MCP intercambia token de usuario por un token de servidor vía flujo OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Servidor MCP usa su propio token OBO para llamadas descendentes
El token OBO:
La guía OWASP GenAI hace una recomendación específica: emitir tokens de acceso con tiempos de vida medidos en minutos, no horas. Esto aplica tanto a los tokens que el servidor MCP acepta de clientes como a los tokens que obtiene para acceso a servicios descendentes.
Un token de acceso robado es válido por su tiempo de vida completo sin importar si el usuario legítimo ha cerrado sesión, cambiado su contraseña o revocado su sesión. Un token de 24 horas robado al inicio de una sesión da a un atacante 24 horas de acceso persistente. Un token de 5 minutos robado a mitad de sesión da como máximo 5 minutos.
Los tokens de corta duración también fuerzan eventos de reautenticación regulares, que proporcionan oportunidades para:
Cada token debería llevar solo los alcances necesarios para la operación específica que se está realizando. No emitas un token con alcance read:files write:files delete:files cuando la llamada de herramienta actual solo necesita read:files. Esto limita el daño si el token es interceptado o el modelo es manipulado para hacer llamadas de herramientas inesperadas.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mapear herramienta a alcances mínimos requeridos
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # tiempo de vida de 5 minutos
)
Obtén los últimos consejos, tendencias y ofertas gratis.
Un error común es usar IDs de sesión como proxies de autorización: si una solicitud lleva un ID de sesión válido, el servidor asume que está autorizada. Esto confunde la gestión de estado con la verificación de identidad.
El modelo correcto: los IDs de sesión gestionan el estado conversacional. La autorización se verifica independientemente en cada solicitud validando las reclamaciones del token OAuth. Incluso una solicitud que lleva un ID de sesión válido debe presentar un token OAuth válido, no expirado y con alcance apropiado antes de que se permita cualquier invocación de herramienta.
Esto importa porque los IDs de sesión pueden ser robados, adivinados o reproducidos de maneras que los tokens OAuth — que llevan garantías de integridad criptográfica — no pueden.
En lugar de implementar verificaciones de autorización dispersas en manejadores de herramientas individuales, la guía OWASP GenAI recomienda una puerta de enlace de políticas centralizada que:
La centralización asegura que las políticas se apliquen consistentemente en todas las herramientas y agentes. Una verificación de autorización específica de herramienta puede ser olvidada o evitada durante el desarrollo; una verificación de puerta de enlace no puede.
Para servidores MCP remotos, el estándar mínimo de seguridad de autenticación es:
Arshia es ingeniera de flujos de trabajo de IA en FlowHunt. Con formación en ciencias de la computación y una pasión por la IA, se especializa en crear flujos de trabajo eficientes que integran herramientas de IA en las tareas cotidianas, mejorando la productividad y la creatividad.
Nuestro equipo de seguridad evalúa configuraciones de autenticación MCP, manejo de tokens y flujos de autorización según los estándares OWASP GenAI. Identifica brechas antes de que lo hagan los atacantes.
Los servidores MCP exponen una superficie de ataque única que combina riesgos tradicionales de API con amenazas específicas de IA. Aprende las 6 vulnerabilidade...
El Servidor MCP de la App Authenticator permite a los agentes de IA acceder de forma segura a códigos 2FA y contraseñas, agilizando los procesos de inicio de se...
El Proyecto de Seguridad GenAI de OWASP define una barra mínima de cinco categorías para el despliegue seguro de servidores MCP. Utilice esta lista de verificac...
Consentimiento de Cookies
Usamos cookies para mejorar tu experiencia de navegación y analizar nuestro tráfico. See our privacy policy.