Autenticación y autorización de MCP: explicación de las diferencias clave

Cuando un agente de IA se conecta a un servidor MCP, el agente debe verificar su identidad (autenticación MCP) y definir las funciones que puede ejecutar una vez que se le concede el acceso (autorización MCP) para garantizar la seguridad tanto del cliente MCP como del sistema. Es fundamental diferenciar entre estos dos tipos de comprobaciones de control de acceso.

Cuando las comprobaciones de seguridad se utilizan de forma incorrecta o intercambiable, surgen brechas de seguridad que plantean desafíos para los usuarios y administradores de los sistemas tradicionales. En los entornos MCP, la falta de controles de seguridad definidos crea riesgos más graves que en los sistemas tradicionales.

Esta guía proporciona descripciones detalladas de la autenticación y autorización de MCP, cómo funcionan dentro del ecosistema de protocolos de contexto modelo y qué se necesita para implementar estos conceptos para una adopción empresarial exitosa en un entorno de producción en vivo.

¿Qué es la autenticación MCP?

La autenticación MCP es el primer punto de verificación entre un cliente MCP y un servidor MCP. Antes de ejecutar cualquier comando mediante herramientas, el cliente debe identificarse y autenticarse para establecer la confianza. Para autenticarse en servidores MCP remotos (HTTP/HTTPS), el mecanismo de autorización más utilizado es OAuth 2.1 con PKCE.

Cuando un agente se autentica correctamente en un servidor de autorización, el cliente intercambia las credenciales por un token de OAuth, a menudo mediante un intercambio de tokens iniciado en el punto final de los metadatos. El servidor MCP no permitirá la conexión a menos que el agente tenga un token de OAuth válido.

A diferencia de los métodos de conexión estándar, los servidores MCP locales que se conectan mediante el transporte STDIO no requieren un agente para autenticarse. En su lugar, utilizan el límite de confianza del proceso anfitrión, que a menudo se configura mediante variables de entorno en casos de uso básicos.

Los tipos de credenciales más utilizados son los siguientes:

• Tokens de acceso de OAuth 2.1: De corta duración (normalmente una hora) y de alcance limitado, este es el tipo de credencial recomendado para un acceso seguro en sistemas de producción.
• Claves de API: Fácil de usar, sin caducidad ni control de acceso detallado; este tipo de credenciales se considera riesgoso cuando se administran muchos usuarios en sistemas externos.
• JWT: Las afirmaciones sobre la identidad de los usuarios, como el usuario, el rol y el inquilino, están integradas en el JWT, aunque conllevan una complejidad adicional debido a la necesidad de una lógica de autorización adicional.
  

Desde la actualización de junio de 2025 de la especificación MCP, los servidores ahora se tratan como servidores de recursos de OAuth y validan los tokens, pero no los emiten a los usuarios. En cambio, la responsabilidad de emitir los tokens se ha trasladado a proveedores de identidad externos, como Okta, Azure AD y Auth0.

Esto crea un punto único de autenticación de MCP y aporta la auditabilidad a nivel de identidad, SSO y MFA al ecosistema de MCP sin necesidad de implementaciones personalizadas.

¿Qué es la autorización MCP?

La autenticación establece la identidad del cliente, mientras que la autorización MCP determina las capacidades del cliente.

La autorización rige el control de acceso a un nivel muy detallado y establece restricciones sobre qué herramientas se pueden invocar, a qué datos se puede acceder y en qué condiciones se pueden tomar esas acciones. La autorización se evalúa de forma continua, en lugar de evaluarla una sola vez, para cada invocación de una herramienta.

En los sistemas MCP, la autorización suele utilizar un enfoque por capas. Las capas de autorización que se encuentran en los sistemas MCP incluyen:

• Permisos basados en el alcance: Permisos definidos en el momento de la emisión del token que establecen los límites exteriores de todos los posibles ámbitos de OAuth y las acciones emprendidas.
• Control de acceso basado en roles (RBAC): Asignación de permisos a roles para garantizar que todos los usuarios y todos los agentes de IA que accedan al mismo rol tengan los mismos derechos para acceder a esos recursos.
• Controles a nivel de recursos: Restringir el acceso seguro a conjuntos de datos, herramientas o entornos específicos.
• Políticas contextuales: Aplicar condiciones de ejecución, como el tiempo, los patrones de solicitud o las señales de riesgo, a lo anterior

La última capa de autorización representa el aspecto más interesante del marco moderno de autorización del MCP. A un token que haya sido autorizado a llamar al método read_file a las 9 a.m., también se le puede denegar la posibilidad de llamar al mismo método a las 2 a.m., según otra política aplicable a los dos primeros parámetros de referencia.

Autenticación frente a autorización en MCP: las diferencias clave

Si bien la autenticación y la autorización a veces se confunden, representan un enfoque de dos niveles en el contexto del MCP. Las dos áreas proporcionan diferentes niveles de control de acceso y los modos de falla de cada una difieren en consecuencia.

Si la autenticación es correcta pero no se aplica la autorización adecuada, cada cliente autenticado se convierte en superusuario.

Los modos de falla a menudo se oponen entre sí:

• La autenticación MCP débil permite el paso de identidades incorrectas.
• Una autorización MCP débil permite que las identidades correctas realicen acciones excesivas.

Los sistemas MCP de estilo de producción requieren que ambos tipos de control se apliquen de forma independiente

¿Cómo funcionan juntas la autenticación y la autorización de MCP en un flujo de MCP real?

A continuación se muestra un ejemplo real de una secuencia de pasos que se llevan a cabo cuando un agente contacta con un servidor MCP remoto. Esto provocará que la llamada a la herramienta se realice correctamente o provocará un error.

Paso 1: El agente intenta conectarse al servidor MCP como cliente MCP. El servidor MCP no reconoce que el cliente tiene una sesión abierta, por lo que devuelve una respuesta 401 no autorizada junto con los metadatos del servidor de autorización que apuntan al servidor de autorización.

Paso 2: El agente envía una solicitud de redireccionamiento al servidor de autorización (Okta, Azure AD o Auth0), donde se completa el flujo de OAuth con PKCE. El usuario o el servicio se autentica y da su consentimiento a los ámbitos de OAuth solicitados y recibe un código de autorización.

Paso 3: Tras recibir un código de autorización del servidor de autorización, el agente usa el flujo del código de autorización para obtener un token de acceso desde el punto final del token. Un token de acceso proporciona al agente un acceso seguro temporal y, al mismo tiempo, confirma la autenticidad de la comunicación y limita al agente a los ámbitos de OAuth aprobados declarados en nombre de la aplicación solicitante.

Paso 4: Al obtener un token de acceso, el agente se comunica con MCP al incluir el token de acceso en el encabezado de autorización como un token de portador. El servidor MCP valida la firma, la fecha de caducidad y la entidad emisora del token comparándolas con las claves públicas del servidor de autorización durante la validación del token para confirmar la identidad del agente.

Paso 5: Cuando el agente llama al servidor MCP con el ámbito tools:read, el servidor MCP comprueba primero si los alcances de los tokens de acceso coinciden con la acción solicitada. Como las herramientas: read scope no permiten acciones destructivas, el servidor MCP devuelve un código de respuesta prohibido 403 y registra la denegación de acceso como parte del flujo de autorización.

Paso 6: Para evitar que los flujos de trabajo de automatización no autorizados lleguen a los servidores mal configurados, se coloca un motor de políticas o una puerta de enlace MCP delante del servidor MCP. El motor de políticas comprueba que cada vez que se invoca una herramienta no supera ningún límite de velocidad ni infringe ninguna política basada en el contexto o regla basada en el alcance antes de permitir que la solicitud pase a la lógica del servidor.

¿Dónde fallan los equipos con la autenticación y la autorización de MCP?

Incluso los equipos que utilizan ambas capas suelen hacer un mal uso de ellas.

• Tratar un token válido como un permiso general: Algunas empresas utilizan tokens válidos para el acceso general, por lo que los desarrolladores suelen establecer nuevos tokens que les otorgan derechos que no deberían tener y, mediante estos tokens, los utilizan para acceder a los recursos de la base de datos de producción únicamente a nivel de desarrollador o mediante el uso de la seguridad de autenticación de tokens para acceder a los recursos de la base de datos por error cuando se establecieron inicialmente de una manera que proporcionaba dichos derechos al desarrollador.
• Se omite la autorización para los servidores MCP internos: Un límite de red por sí solo no garantiza que no pueda acceder a ellos. Una persona con acceso interno puede acceder a todos los recursos internos del servidor interno de aplicaciones de procesamiento de pedidos de venta.
• Claves de API estáticas utilizadas sin una pila de autorizaciones adecuada: Es posible que las claves de API estáticas no tengan alcances, mecanismos de caducidad o revocación de OAuth. Si se publica una clave de API estática en un archivo de registro o repositorio, la única solución es rotar las credenciales, lo que es perjudicial desde el punto de vista operativo a escala.
• Confiar únicamente en los ámbitos de OAuth sin RBAC a nivel de puerta de enlace: Los ámbitos de OAuth definen lo que el token puede realizar dentro de una sesión, mientras que los roles definen lo que se le asigna a la persona. Si el RBAC no se aplica a nivel de puerta de enlace, una canalización automatizada tendrá el mismo acceso que un ingeniero humano.
• No volver a evaluar el acceso una vez que se ha otorgado el permiso al inicio de una sesión: Cuando se concede permiso a un agente de IA para realizar su función al principio de la sesión, si el rol del agente cambia durante la sesión, todos los permisos concedidos antes de ese cambio seguirán aplicándose durante todo el período. Este es un riesgo importante en los sistemas de agencias, en los que los agentes autónomos pueden operar durante sesiones prolongadas.

¿Qué requiere la implementación empresarial de la autenticación y autorización de MCP?

No es posible que los equipos o las implementaciones de servidores individuales gestionen la autenticación de MCP y la autorización de MCP a escala por sí solos. Más bien, deberían implementarse en varios servidores a nivel de plataforma.

Para ello, se debe tener en cuenta lo siguiente:

• Administración de identidades centralizada mediante un proveedor de identidades: Todas las solicitudes de autenticación de MCP en los servidores de MCP deben pasar por el mismo proveedor de identidad, ya sea Okta, Azure AD o Auth0. La configuración de autenticación distribuida no escalará y creará fragmentación en los registros de auditoría.
• Tokens de alcance efímero aplicados por la infraestructura: Todos los servidores MCP deben aplicar tokens de acceso de corta duración con alcances de OAuth definidos en toda la infraestructura. El equipo no puede definir correctamente la caducidad o el alcance de los tokens para cada implementación, pero la infraestructura los aplicará de manera coherente.
• RBAC por servidor y rol con propagación inmediata de políticas: Cuando un equipo cambia el rol de un usuario o miembro del equipo, el cambio debe propagarse inmediatamente a todos los servidores y hacerse efectivo sin esperar al siguiente ciclo de implementación.
• Registros de auditoría combinados únicos para los registros de acceso y autorización: Los diferentes equipos requieren tanto los registros de acceso como los registros de autorización de MCP. Ambos equipos necesitan acceder a registros de auditoría combinados utilizando un identificador de solicitud común para futuras investigaciones.
• Aplicación del control de acceso a la puerta de enlace separada del código de la aplicación: Si la política de la aplicación está almacenada en el servidor y el servidor se implementa de forma incorrecta, la política de la aplicación se puede deshabilitar sin que se detecte. Sin embargo, la puerta de enlace MCP aplicará tanto las comprobaciones de los alcances como los límites de velocidad de OAuth, independientemente del comportamiento de la aplicación.

¿Cómo aplica TrueFoundry la autenticación y autorización de MCP en la capa de plataforma?

TrueFoundry trata la autenticación y autorización de MCP como conceptos fundamentales de su plataforma, no como tareas que deben realizar aplicaciones individuales.

• Integración de IdP empresarial lista para usar: TrueFoundry permite a las organizaciones conectar su proveedor de identidad empresarial mediante Okta, Azure AD o cualquier servidor de autorización de OAuth compatible con OAuth 2.0. Los tokens de autenticación se aprovisionan y la verificación de identidad se realiza a través de la infraestructura de identidad existente de cada organización. Las organizaciones no necesitan crear ni administrar un servidor de autorización adicional para completar sus solicitudes.
• El RBAC por servidor se aplica en la puerta de enlace, no en la aplicación: Al aplicar el control de acceso en la puerta de enlace MCP antes de que una solicitud llegue a la lógica de la aplicación del servidor MCP, TrueFoundry garantiza que las políticas de acceso se apliquen en varias instancias de MCP, independientemente de cómo se desarrolle o implemente cada instancia de aplicación.
• Acceso por ámbito que asigna las funciones organizativas a los permisos de las herramientas: TrueFoundry admite el alcance de la autorización de MCP, con un grupo, como Finanzas, asignado a un conjunto de herramientas y otro, como Support, asignado a otro. Un agente financiero y un agente de soporte pueden acceder a la misma infraestructura de MCP y, al mismo tiempo, disponer de distintos permisos para utilizar las herramientas. La asignación entre las funciones y los ámbitos de OAuth se define una vez en la plataforma y se aplica en todas las instancias.
• Registro de auditoría unificado dentro de su VPC: TrueFoundry proporciona una única pista de auditoría consolidada dentro de la VPC del cliente para los eventos asociados con la validación de tokens y las invocaciones de herramientas. Los equipos de seguridad tienen acceso a un registro de auditoría completo y correlacionado con el tiempo. Todos los eventos de validación de tokens e invocación de herramientas incluyen un identificador de solicitud uniforme, lo que facilita la identificación de los eventos relacionados con un usuario específico en grandes modelos lingüísticos y herramientas externas.
• Configuración predeterminada de la plataforma, no por equipo: Las funciones de autenticación MCP y autorización MCP están habilitadas de forma predeterminada en todas las organizaciones. Las aplicaciones de MCP siempre heredan estas políticas al implementar agentes de IA, por lo que los equipos no necesitan crear sus propias políticas ni implementar la autenticación adecuada en cada nuevo servidor de MCP.

TrueFoundry proporciona la autenticación y la autorización de MCP como capacidades fundamentales de la plataforma, y no como una carga de configuración individual para las organizaciones que utilizan sus herramientas.

Preguntas frecuentes

¿Qué son la autenticación MCP y la autorización MCP?

La autenticación MCP y la autorización MCP son dos conceptos de seguridad independientes. La autenticación MCP confirma la identidad del cliente MCP antes de conceder el acceso mediante claves de API o tokens de OAuth. La autorización MCP determina lo que el cliente autenticado puede hacer mediante los ámbitos de OAuth y el RBAC. Ambas son necesarias en cualquier implementación de un servidor MCP de producción para evitar riesgos de seguridad derivados del acceso no autorizado.

¿Cuál es la diferencia entre la autenticación y la autorización en MCP?

La autenticación MCP se produce una vez al conectarse y utiliza el flujo del código de autorización o el flujo de credenciales del cliente para verificar la identidad. La autorización del MCP se evalúa cada vez que se invoca una herramienta durante la conexión, y se aplican los ámbitos de OAuth y las reglas de RBAC a cada solicitud que el agente de IA realiza a través del servidor MCP

¿Se puede obtener la autorización de MCP sin autenticación?

No es posible una autorización MCP significativa sin la autenticación MCP, porque no hay ninguna identidad autenticada con la que evaluar los permisos. Sin la autenticación adecuada para establecer la identidad, el servidor de autorización no tiene ninguna base para emitir tokens de acceso o aplicar la lógica de autorización a las solicitudes entrantes de agentes de IA o agentes autónomos.

¿Qué es lo primero, la autenticación MCP o la autorización MCP?

La autenticación MCP siempre es lo primero. El flujo de autorización establece la identidad del cliente MCP con el servidor de autorización. A continuación, se autoriza el MCP para cada solicitud posterior, una vez que se haya completado la autenticación del cliente y se hayan emitido los tokens de acceso con alcances de OAuth definidos.

¿TrueFoundry admite la opción de traer su propio IdP?

Sí. TrueFoundry se integra con cualquier proveedor de identidad o servidor de autorización de OAuth que cumpla con OAuth 2.0, lo que permite a las organizaciones reutilizar su infraestructura de identidad existente. Esto incluye la compatibilidad con proveedores de identidad externos, como Okta y Azure AD, lo que permite la autenticación MCP centralizada en todos los servidores MCP sin crear una configuración de servidor de autorización independiente.