Servidor MCP de la App Authenticator
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...
5 min de lectura
MCP
Security
+5
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.
El Desafío de la Autenticación en MCP
Los servidores MCP enfrentan un panorama de autenticación más complejo que los servicios tradicionales porque median entre múltiples principales:
- El usuario cuyas instrucciones impulsan el asistente de IA
- El modelo de IA que interpreta instrucciones y llama a herramientas
- El cliente MCP (la aplicación que aloja la IA)
- El servidor MCP que ejecuta llamadas a herramientas
- Servicios descendentes que el servidor MCP llama en nombre del usuario
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.
Obligatorio: OAuth 2.1 y OIDC para Servidores Remotos
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.
Qué Validar en Cada Solicitud
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.
Entornos de Cliente Dinámicos
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.
¿Listo para hacer crecer tu negocio?
Comienza tu prueba gratuita hoy y ve resultados en días.
El Problema del Diputado Confundido
Entendiendo el Ataque
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:
- La usuaria Alice está autenticada en un servidor MCP con permisos limitados — puede leer sus propios archivos pero no los de otros
- El servidor MCP tiene amplios permisos de cuenta de servicio para leer todos los archivos en la organización
- El servidor MCP usa token passthrough: reenvía el token de Alice a servicios descendentes
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.
Por Qué el Token Passthrough Crea Esta Vulnerabilidad
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:
- Rompe las pistas de auditoría (los registros descendentes muestran identidad de usuario, no identidad de servidor, oscureciendo la capa MCP)
- Da a un atacante que compromete el servidor MCP acceso a todos los tokens de usuario reenviados
- Crea problemas de cumplimiento si los tokens para diferentes usuarios pueden ser confundidos o reproducidos
La Solución: Delegación Explícita de Tokens con Flujos On-Behalf-Of
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:
- Está explícitamente limitado a los permisos mínimos necesarios para la llamada de herramienta específica
- Identifica al servidor MCP como la parte que llama (con el usuario como el sujeto)
- Está vinculado al evento de autenticación del usuario (puede ser revocado cuando termina la sesión del usuario)
- No expone el token completo del usuario a servicios descendentes
Tokens de Corta Duración y Alcance Limitado
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.
Por Qué Importan los Tiempos de Vida Cortos
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:
- Volver a verificar si la cuenta del usuario ha sido suspendida o sus permisos han cambiado
- Detectar patrones de autenticación anómalos (tiempos, ubicaciones o frecuencia inusuales)
- Aplicar autenticación escalonada para operaciones sensibles
Minimización del Alcance del Token
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
)
Únete a nuestro boletín
Obtén los últimos consejos, tendencias y ofertas gratis.
Tratando las Sesiones como Estado, No como Identidad
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.
Aplicación Centralizada de Políticas
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:
- Intercepta todas las solicitudes de invocación de herramientas antes de que lleguen al código específico de la herramienta
- Valida la autenticación (firma del token, emisor, audiencia, expiración)
- Aplica la autorización (alcance requerido para esta herramienta específica)
- Aplica la verificación de consentimiento (¿ha autorizado explícitamente el usuario este tipo de acción?)
- Implementa filtrado de herramientas (¿está permitida esta herramienta en este contexto de despliegue?)
- Registra todas las decisiones con contexto completo para auditoría
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.
Resumen: La Lista de Verificación de Autenticación
Para servidores MCP remotos, el estándar mínimo de seguridad de autenticación es:
- OAuth 2.1 / OIDC aplicado para todas las conexiones
- Firma del token, emisor, audiencia y expiración validados en cada invocación de herramienta
- Sin token passthrough a APIs descendentes — usar OBO o tokens emitidos por el servidor
- Tokens de acceso limitados a permisos mínimos requeridos por herramienta
- Tiempos de vida de tokens medidos en minutos con actualización obligatoria
- IDs de sesión no usados como proxies de autorización
- Puerta de enlace de aplicación de políticas centralizada implementada
- Todos los eventos de autenticación y decisiones de autorización registrados de manera inmutable
Recursos Relacionados
- Seguridad del Servidor MCP: 6 Vulnerabilidades Críticas
- Lista de Verificación de Seguridad MCP: El Estándar Mínimo para Despliegue Seguro
- Seguridad de API LLM: Limitación de Tasa, Autenticación y Prevención de Abuso
- Asegurando Agentes de IA: Prevención de Ataques Multi-Paso
- Auditoría de Seguridad de Chatbot de IA: Qué Esperar
