Explicación de la autenticación MCP: cómo funciona y por qué es importante

La autenticación y la autorización de MCP no siempre han sido tan seguras como lo son en la actualidad. Cuando MCP comenzó a implementarse, la autenticación se realizaba normalmente mediante claves de API, que a menudo se incluían en un archivo de configuración o como variables de entorno, lo que permitía un acceso estático, compartido y sin ámbito. Si se filtraba esta clave, se concedía a un usuario malintencionado un acceso total, sin posibilidad de rastrear o controlar lo que se hacía.

La especificación MCP evolucionó rápidamente para abordar este problema:

• marzo de 2025: OAuth 2.1 se definió como el estándar para autenticar una aplicación o un usuario en una API.
• junio de 2025: Los servidores MCP se redefinieron como servidores de recursos de OAuth y la capacidad de emitir tokens se trasladó a proveedores de identidad externos.
• noviembre de 2025: PKCE pasó a ser obligatorio para todas las aplicaciones del lado del cliente y el CIMD se definió como una forma de identificar de forma única cada instancia del cliente.

En menos de un año, el método de autenticación MCP pasó de los secretos estáticos a un modelo coherente con los sistemas de identidad empresariales modernos.

Esta guía describe qué es la autenticación MCP, cómo funciona, los posibles enfoques para implementarla, dónde fallan las implementaciones y cómo implementarla correctamente a escala.

¿Qué es la autenticación MCP?

La autenticación MCP es el proceso mediante el cual un servidor MCP verifica la identidad de un solicitante antes de ejecutar cualquier herramienta.

Sin la autenticación MCP, cualquier cliente MCP que pudiera acceder a un servidor MCP podría invocar sus herramientas, independientemente de la identidad, la función o la intención de ese cliente. Si las herramientas invocadas establecen una conexión con sistemas externos críticos, como los CRM, las bases de datos o los servicios en la nube, se crearía una vía sin restricciones para la producción de datos confidenciales.

No se trata de un riesgo teórico. Una vulnerabilidad del CVSS 9.6 en el paquete mcp-remote permitía a los servidores MCP malintencionados aprovechar el flujo de OAuth del paquete para ejecutar comandos arbitrarios del sistema operativo de forma remota, lo que afectaba a cientos de miles de descargas.

La autenticación MCP se realiza a través de la capa de transporte antes de que se ejecute la herramienta. La forma de ejecución depende de cómo se implemente el servidor MCP:

• Transporte STDIO (servidores locales): se ejecuta como un proceso local; la autenticación de MCP puede usar variables de entorno o credenciales de sistema fuera de MCP.
• HTTP transmisible (servidores remotos): se ejecuta en la red sin confianza compartida entre el cliente y el servidor MCP. La autenticación MCP se realiza mediante OAuth 2.1 con tokens de acceso adjuntos a cada solicitud.

En la práctica:

• Desarrollo local: las credenciales basadas en el medio ambiente pueden ser suficientes.
• Sistemas de producción remota: se requiere OAuth 2.1 para una autenticación adecuada.

Los tres tipos de autenticación MCP

Métodos de autenticación utilizados en diferentes implementaciones de MCP según el entorno y la tolerancia al riesgo

Claves de API y tokens estáticos

Es un método sencillo de pasar una clave previamente acordada con cada solicitud.

Autorización: Bearer sk-xxxx

Cuándo funciona:

• En el desarrollo local y mediante una herramienta interna que opera dentro de un límite de red bien definido.

Limitaciones:

• Los tokens estáticos no tienen caducidad
• Los tokens estáticos no tienen identidad de usuario
• Sin permisos granulares
• Los tokens estáticos se pueden filtrar a través de registros o controles de versiones, lo que es bastante arriesgado.
• Cuando se exponen los tokens estáticos, el control de acceso total al sistema asociado permanecerá activo hasta que se desactive manualmente

OAuth 2.1 con PKCE (estándar para servidores MCP remotos)

A partir de la actualización de la especificación MCP de marzo de 2025, el estándar para proteger los servidores MCP remotos mediante la autenticación MCP es OAuth 2.1 con PKCE. En lugar de credenciales estáticas, este enfoque utiliza un flujo de autorización seguro y basado en tokens que permite la transmisión de HTTP.

Cómo funciona:

• Descubrimiento de metadatos: El cliente MCP intenta descubrir los metadatos del servidor de autorización requeridos en el servidor sin un token de acceso y recibe una respuesta 401. El documento de metadatos del recurso protegido indica al cliente a qué servidor de autorización debe conectarse y qué ámbitos necesarios están disponibles.
• Registro de clientes: El cliente MCP se registra en el servidor de autorización. El método predeterminado desde noviembre de 2025 es mediante el protocolo CIMD. El cliente publica los metadatos de su identificador de cliente en una URL pública que controla y el servidor de autorización valida la información del cliente en tiempo de ejecución.
• Código de autorización: El cliente abre el navegador del usuario, solicita al usuario que inicie sesión y dé su consentimiento, y recibe un código de autorización del servidor de autorización para actuar en su nombre.
• Emisión del token de acceso: El cliente intercambia el código de autorización mediante el flujo del código de autorización por un token de acceso con el alcance del recurso solicitado e incluye este token en cada solicitud de MCP.

Por qué es importante PKCE:

• PKCE protege contra los ataques de interceptación al garantizar que el usuario que completa la autenticación MCP es la misma persona que la inició.
• El PKCE es obligatorio para todos los clientes de MCP a partir de noviembre de 2025 según las especificaciones actuales de MCP.

Credenciales basadas en el entorno (servidores STDIO)

Los servidores MCP locales heredan las credenciales de su propio entorno de ejecución.

Ventajas:

• Fácil de configurar sin flujo de autorización externo.

Contras:

• Las credenciales son accesibles para cualquier proceso que pueda acceder al sistema MCP, lo que crea riesgos en todas las fuentes de datos.
• Difícil de administrar entre varias personas o equipos sin una lógica de autorización centralizada.
• Sin gobierno centralizado ni control de acceso.

En los entornos de producción, debe recuperar las credenciales de forma dinámica mediante un almacén seguro en lugar de almacenarlas en texto sin formato.

Cómo funciona la autenticación MCP OAuth 2.1 paso a paso

Cuando un cliente MCP se conecta a un servidor MCP protegido, se produce el siguiente flujo MCP:

• Paso 1: el cliente se conecta, el servidor rechaza: El cliente MCP intenta realizar una solicitud sin ningún token. El servidor responde con un error 401 no autorizado y un puntero a la URL de metadatos de su recurso protegido como parte del descubrimiento del servidor de autorización.
• Paso 2: El cliente recupera los metadatos: El punto final de metadatos especifica qué servidor de autorización usar, qué ámbitos de OAuth están disponibles y dónde ubicar el punto final del token.
• Paso 3: El cliente se registra e inicia el flujo de OAuth: El cliente se identifica mediante CIMD y el documento de metadatos de su identificador de cliente, crea un verificador de código PKCE y un desafío de código y, a continuación, redirige el navegador del usuario a la página de inicio de sesión del servidor de autorización.
• Paso 4: El usuario se autentica y recibe el código de autorización: El usuario inicia sesión y da su consentimiento. El servidor de autorización devuelve un código de autorización para que el cliente lo intercambie mediante el verificador de código original por un token de acceso limitado y de corta duración.
• Paso 5: El cliente llama al servidor MCP con el token portador: Cada solicitud de MCP incluye el token de acceso en el encabezado del portador de la autorización. El servidor MCP valida los alcances del emisor, la audiencia, la caducidad y la OAuth. Si el token de acceso no incluye los alcances necesarios, el servidor responde con un 403 y solicita una autorización de usuario adicional, una función que se introdujo en noviembre de 2025.

¿Dónde sigue fallando la autenticación MCP?

Muchas implementaciones crean graves riesgos de seguridad de MCP debido a una implementación incorrecta de la autenticación y autorización de MCP, incluso cuando se usa OAuth.

• Tokens estáticos en los archivos de configuración: Las claves de API se guardan en los repositorios de Git, se comparten en archivos mcp.json o .env y se han olvidado. Un único identificador de cliente de OAuth comprometido proporciona acceso ilimitado y nunca caduca, lo que crea una fuente persistente de acceso no autorizado.
• Alcances de OAuth sobreautorizados: Los usuarios solicitan una gran cantidad de ámbitos de OAuth durante la configuración, pero no los restringen al ejecutar la aplicación. Un agente de IA configurado como de solo lectura debe almacenarse con un token de acceso con ámbito de lectura en lugar de un token de lectura/escritura/eliminación.
• Sin rotación de tokens en las implementaciones autogestionadas: Los tokens de OAuth de larga duración se emiten para despliegues autogestionados sin proceso de rotación. Si un token se ve comprometido, sigue funcionando como un token portador válido hasta que alguien lo desactive manualmente.
• No hay registro de auditoría para las llamadas a herramientas: Cuando se emite un token y se accede a herramientas externas, no existe ningún registro que indique quién hizo la solicitud MCP original, lo que hace imposible que los miembros del equipo de seguridad investiguen la causa raíz.

La mayoría de estos problemas se resuelven cuando las organizaciones migran de las claves estáticas a OAuth 2.1, lo que permite utilizar tokens de acceso de corta duración, ámbitos de OAuth con ámbito limitado y registro de auditoría centralizado a través del servidor de autorización.

Los requisitos de autenticación de MCP empresariales en comparación con la forma en que TrueFoundry los resuelve

TrueFoundry elimina la complejidad de administrar múltiples formas de autenticación y autorización de MCP en equipos individuales y aplica controles uniformes en todos los servidores de MCP a través de una única capa de puerta de enlace de MCP.

Reserva una demostración para entender cómo MCP gestiona la autenticación a nivel de infraestructura

Preguntas frecuentes

¿Qué es la autenticación MCP? 

La autenticación MCP es el proceso de verificación de la identidad de una entidad que intenta conectarse a un servidor MCP mediante tokens de OAuth, claves de API o variables de entorno según el contexto de implementación. Solo permite a los agentes de IA y clientes de MCP verificados acceder a herramientas y servicios externos, lo que constituye la primera capa de autenticación y autorización de MCP en cualquier sistema de producción.

¿MCP requiere OAuth? 

No en todos los casos. Es posible que un servidor de transporte STDIO local no implemente un flujo de OAuth formal. Sin embargo, cualquier servidor MCP remoto que gestione datos importantes para la producción o herramientas externas debe utilizar OAuth 2.1 con PKCE como mecanismo de autorización estándar según la especificación MCP actual para aplicar correctamente la autenticación y la autorización de MCP.

¿MCP tiene autenticación? 

MCP admite la autenticación y la autorización de MCP, y el método depende del entorno del servidor. Los servidores remotos utilizan OAuth 2.1 PKCE como flujo de autorización estándar. Los servidores de transporte STDIO locales se autentican con las credenciales de las variables de entorno o del proceso host. La especificación MCP estableció oficialmente que OAuth 2.1 fuera el estándar para las implementaciones remotas a partir de marzo de 2025.

¿Cuáles son los tipos de autenticación MCP? 

Existen tres métodos comunes para la autenticación y autorización de MCP: claves de API estáticas para casos de uso internos o de desarrollo, OAuth 2.1 con PKCE para todas las implementaciones de servidores MCP remotos, según lo exige la especificación de MCP, y credenciales basadas en el entorno mediante variables de entorno para los servidores de transporte STDIO locales donde no se requiere un flujo formal de registro de clientes de OAuth.

¿Cómo funciona la autenticación MCP? 

Cuando un cliente MCP se conecta a un servidor MCP protegido, el servidor devuelve un 401 con un puntero al documento de metadatos de su recurso protegido. El cliente detecta el servidor de autorización, se registra mediante CIMD, completa el flujo del código de autorización con PKCE y recibe un token de acceso limitado. Este token se incluye en todas las solicitudes entrantes de validación del token antes de permitir cualquier llamada a la herramienta.

¿Cómo gestiona TrueFoundry la autenticación MCP? 

A través de la puerta de enlace MCP, TrueFoundry centraliza la autenticación y la autorización de MCP al integrarse con los proveedores de identidad empresariales y gestionar la emisión, rotación y validación de los tokens de acceso automatizados. Los ámbitos de OAuth y las políticas de RBAC se aplican a nivel de puerta de enlace en todos los servidores MCP, y los registros de auditoría estructurados se conservan en la VPC del cliente para garantizar su cumplimiento por parte de los agentes de IA y los servicios externos.