Esto es lo que nadie explica con claridad sobre la autorización de MCP: no es una capa de seguridad personalizada inventada por Anthropic. Es OAuth 2.1 aplicado a un nuevo contexto específico, con un conjunto de asignaciones de roles que la especificación define con precisión. La confusión no tiene que ver con la tecnología. Tiene que ver con qué componente hace qué y dónde está el límite entre el componente que emite tokens y el componente que los aplica.
He visto cómo esta confusión provoca fallos en producción siguiendo un patrón que ya es casi predecible. Un equipo conecta un servidor MCP, confirma que el cliente puede conectarse y lo considera «autorizado». Tres meses después, alguien pregunta por qué un agente puede llamar a una herramienta de escritura que nunca debió poder usar. La respuesta suele ser que el token se emitió correctamente, pero nadie implementó la aplicación de ámbitos en el lado del servidor. Dos problemas distintos. Una solución que no se implementó.
La especificación de autorización de MCP es concreta. Tiene roles diferenciados, dependencias RFC específicas y patrones no negociables para el movimiento de tokens. Comprender estos patrones es lo que diferencia una configuración que funciona de una que solo parece funcionar hasta que deja de hacerlo.
La parte que los equipos aprenden demasiado tarde
- La autorización de MCP es OAuth 2.1 aplicado a contextos de agentes de IA, no un protocolo nuevo inventado para MCP.
- El servidor de autorización y el servidor MCP tienen funciones independientes que no se solapan; confundirlas es donde comienzan la mayoría de los fallos en producción.
- La autenticación confirma la identidad; la autorización aplica lo que esa identidad puede hacer. La especificación gestiona ambas, pero a través de mecanismos distintos que deben implementarse individualmente.
- La integración de SSO empresarial exige un trabajo arquitectónico deliberado que va mucho más allá de lo que ofrece la especificación base.
- «Opcional a nivel de protocolo» no significa opcional en producción.
Qué es realmente la autorización de MCP y qué cubre la especificación
La autorización de MCP es el mecanismo mediante el cual los clientes MCP basados en HTTP obtienen tokens de acceso OAuth 2.1 de un servidor de autorización dedicado y presentan esos tokens a servidores MCP que actúan como servidores de recursos. Esta frase tiene tres partes en movimiento, y cada una importa.
El cliente MCP es el consumidor: un agente de IA, un copiloto de IDE o un flujo de automatización que realiza solicitudes. El servidor de autorización es un servicio independiente que autentica al cliente, recopila el consentimiento del usuario y emite tokens. El servidor MCP recibe esos tokens en cada solicitud y los valida antes de permitir la ejecución de cualquier herramienta. Es el servidor de recursos en el modelo OAuth 2.1.
Lo que cubre la autorización en MCP: la especificación del protocolo de contexto de modelo define exactamente cómo ocurre este intercambio de tokens, qué flujos son obligatorios y cómo los clientes descubren el servidor de autorización en primer lugar. Lo que no cubre: lo que sucede dentro de sus API de respaldo una vez que el token supera la validación. Esa brecha importa y volveré a ella.
La parte que la mayoría de los lectores no percibe es que la especificación marca la autorización como opcional a nivel de protocolo, pero esta designación se refiere a la conectividad mínima viable entre un cliente MCP y un servidor MCP en un contexto local y de confianza. Para cualquier servidor MCP basado en HTTP expuesto a clientes no confiables, la propia guía de la especificación no es realmente opcional. La opcionalidad es una designación de la capa de protocolo, no una decisión de seguridad para producción. Los equipos que leen «opcional» y omiten la implementación aprenden esta distinción más tarde de su equipo de seguridad, en condiciones menos favorables.
Por qué el modelo de autorización de MCP se basa en OAuth 2.1 en lugar de un protocolo nuevo
La decisión deliberada de basarse en OAuth 2.1 en lugar de inventar un mecanismo personalizado merece entenderse antes de evaluar cualquier implementación de MCP. La especificación de MCP no necesitaba resolver identidad y consentimiento desde cero. Estos problemas ya tienen soluciones, y esas soluciones ya cuentan con infraestructura detrás.
Esta es una decisión arquitectónica con implicaciones prácticas reales. Si su equipo ya opera infraestructura OAuth 2.1, parte de una superficie de seguridad conocida. Su equipo de seguridad sabe qué auditar. Su IdP sabe con qué integrarse. No está introduciendo una superficie de ataque completamente nueva en su entorno de producción. Esto supone una reducción de riesgo real, no un argumento de marketing.
El análisis técnico de Aembit sobre la especificación de autorización de MCP lo documenta explícitamente: la especificación estandariza el acceso del cliente a recursos protegidos mediante OAuth 2.1 con PKCE e introduce Protected Resource Metadata para desacoplar el control de acceso de los servidores MCP y alinearlo con la infraestructura de identidad existente. La implicación práctica de esa última frase, «alinearlo con la infraestructura de identidad existente», es que los equipos que ya utilizan autorización OAuth pueden conectar MCP a su stack de identidad actual en lugar de crear uno paralelo.
La decisión de aprovechar patrones de autorización existentes importa para los arquitectos que evalúan el riesgo en plazos concretos. Usted audita la implementación, no el protocolo. Los errores en su implementación de autorización de MCP son errores de OAuth 2.1, que tienen rutas de corrección conocidas, CVE documentadas y una comunidad de seguridad que los encontrará. Un protocolo personalizado no ofrece nada de ese historial.
La autorización OAuth en el contexto de MCP también implica que el flujo de código de autorización es el patrón principal, con PKCE obligatorio para clientes públicos. Por qué esta combinación específica tiene sentido quedará claro en la siguiente sección.
Por qué OAuth 2.1 y PKCE son la opción adecuada para clientes de agentes de IA
PKCE (Proof Key for Code Exchange) existe para resolver un problema específico: ¿cómo proteger un intercambio de código de autorización OAuth 2.1 cuando el cliente no puede almacenar un secreto de forma segura? Una aplicación móvil nativa no puede almacenar un secreto de cliente de forma segura. Tampoco puede hacerlo una extensión de navegador. Y tampoco un agente de IA o un copiloto de IDE que se ejecuta como cliente público.
Este es exactamente el caso de uso del host MCP. Cuando un agente de IA actúa en nombre de un usuario, opera como cliente público. Almacenar un secreto de cliente en un proceso de agente que se ejecuta en entornos controlados por el usuario no constituye un control de seguridad significativo. La interceptación de códigos de autorización es una vía de ataque real para estos clientes si el intercambio no está protegido.
PKCE cierra esa brecha. El cliente genera un verificador de código antes de la solicitud de autorización, envía un hash de este —el desafío de código— con la solicitud y después demuestra que posee el verificador original al intercambiar el código de autorización por un token. Un código interceptado es inútil sin el verificador. Los clientes MCP y servidores MCP que operan en escenarios de clientes públicos obtienen una protección significativa del código de autorización sin requerir un secreto que en realidad no puede mantenerse en secreto. Por eso la especificación lo exige: no como recomendación de buenas prácticas, sino como requisito estructural para esta clase de cliente.
Las dependencias RFC que la mayoría de los equipos pasa por alto antes de implementar
La especificación de autorización de MCP no funciona de forma aislada. Depende de un conjunto de RFC que la mayoría de los equipos no inventaría completamente antes de desarrollar. Omitir cualquiera de ellas en sus implementaciones de MCP genera una configuración parcialmente compatible y completamente rota en casos límite específicos.
La lista de verificación que separa las implementaciones compatibles de las defectuosas, basada en los propios requisitos de la especificación y el análisis de campo de Christian Posta:
- OAuth 2.1 con PKCE - el requisito central de flujo para clientes públicos; no es opcional en implementaciones basadas en HTTP
- RFC 8414 - Metadatos del servidor de autorización - permite a los clientes descubrir automáticamente los endpoints del servidor de autorización mediante una URL conocida; sin esto, los clientes requieren configuración codificada
- RFC 9728 - Metadatos de recursos protegidos para autorización - permite al servidor MCP anunciar la ubicación de su servidor de autorización a los clientes que reciben un 401; así es como los clientes saben dónde obtener tokens en primer lugar
- RFC 7591 - Registro dinámico de clientes - permite a los clientes registrarse programáticamente en el servidor de autorización; especialmente importante para herramientas y agentes que no pueden registrarse manualmente con antelación
- RFC 8707 - Indicadores de recursos - permite limitar los tokens a servidores de recursos específicos, reduciendo el riesgo de que un token emitido para un servidor MCP pueda reutilizarse contra otro
Los equipos que implementan OAuth 2.1 pero omiten RFC 9728 terminan con clientes que no pueden descubrir el servidor de autorización sin configuración manual. Los equipos que omiten RFC 7591 tienen una brecha de registro dinámico de clientes que importa en cuanto necesitan incorporar agentes programáticamente a escala. Los metadatos para el descubrimiento del servidor de autorización en RFC 8414 son lo que hace automatizable todo el intercambio. Si los omite, habrá creado algo que funciona en su entorno de pruebas y falla cuando alguien intenta conectar un nuevo tipo de cliente.
Cómo funciona el flujo de autorización de MCP: roles, tokens y límites de responsabilidad
El flujo de autorización en MCP tiene una secuencia específica, y la asignación de roles en cada paso es la parte que más confunde a los equipos. Permítame explicarlo dejando los límites claros, porque es en esos límites donde residen la mayoría de los errores de implementación.
Un cliente intenta llamar a un endpoint protegido de un servidor MCP. El servidor devuelve un 401 con encabezados WWW-Authenticate que apuntan a sus metadatos de recursos protegidos. El cliente obtiene esos metadatos para descubrir la ubicación del servidor de autorización. Después inicia el flujo de código de autorización OAuth 2.1 con PKCE frente a ese servidor de autorización, redirigiendo al usuario para que otorgue consentimiento. El servidor de autorización autentica al usuario, recopila el consentimiento y devuelve un código de autorización. El cliente intercambia ese código, junto con su verificador PKCE, por un token de acceso. En cada solicitud posterior al servidor MCP, el cliente presenta ese token en el encabezado Authorization. El servidor MCP valida el token y aplica el ámbito.
Este es el flujo de autorización de extremo a extremo. Dos cosas ocurren en dos ubicaciones completamente distintas. El servidor de autorización gestiona identidad y consentimiento. El servidor MCP gestiona la aplicación de permisos. Se trata de responsabilidades e implementaciones separadas. Confundirlas es el origen de la mayoría de los fallos de seguridad en producción que veo cuando los equipos informan de problemas con implementaciones de MCP.
Qué controla el servidor de autorización frente a qué aplica el servidor MCP
La división del trabajo es precisa y no negociable. Un servidor de autorización se encarga de la autenticación, la recopilación del consentimiento y la emisión de tokens. El trabajo del servidor MCP comienza después de que el token existe.
El servidor de autorización se encarga de verificar quién es el cliente, confirmar que el usuario ha consentido los ámbitos solicitados, emitir un token de acceso firmado con esos ámbitos integrados y, cuando corresponda, emitir tokens de actualización para sesiones de larga duración. No sabe ni le importa qué hará el servidor MCP con el token una vez que lo reciba. Ese no es un problema que deba resolver el servidor de autorización.
La responsabilidad del servidor MCP comienza al recibir el token. Los servidores MCP deben validar el token en cada solicitud: verificar la firma, comprobar el emisor, confirmar que la reclamación de audiencia coincide con este servidor específico y aplicar las reclamaciones de ámbito frente a la herramienta invocada. La lógica de autorización a nivel del servidor MCP no es un simple reenvío. Es un paso activo de aplicación de permisos por solicitud.
El error común: los equipos integran correctamente el servidor de autorización y luego asumen que el servidor MCP está «autorizado» porque recibió un token válido. Un token criptográficamente válido que contiene los ámbitos incorrectos para la herramienta solicitada debe rechazarse. Ese rechazo ocurre en el servidor MCP. Un servidor de autorización puede atender a varios servidores MCP, pero cada servidor debe definir sus propios requisitos de ámbito y aplicarlos de forma independiente. No puede definir varios servidores de autorización y tratar la aplicación de ámbitos como responsabilidad de otra persona. Nunca lo es.
Ciclo de vida de los tokens de acceso y actualización en un contexto MCP
Los tokens de acceso en MCP siguen el modelo OAuth 2.1: tienen una vida corta, están limitados por ámbito y se validan en cada solicitud. La vida corta no es solo una recomendación. El análisis de Aembit sobre la especificación documenta específicamente que la guía de MCP prohíbe explícitamente las sesiones del lado del servidor y exige la validación de tokens por solicitud. Esto rompe un patrón al que los equipos provenientes de la arquitectura tradicional de aplicaciones web suelen recurrir de forma instintiva.
En una aplicación web basada en sesiones, usted se autentica una vez y la sesión persiste. Un cliente MCP no puede asumir eso. Cada llamada al servidor MCP valida el token de acceso frente al servidor de autorización. No existe un atajo del tipo «ya comprobé a este usuario hace cinco minutos» que permita la especificación. Es una decisión de diseño deliberada para reducir el riesgo de que una sesión comprometida conceda acceso ilimitado durante un periodo prolongado.
El token de actualización existe para sesiones de agentes de larga duración. Cuando un token OAuth caduca a mitad de un flujo —lo que ocurrirá en cualquier sesión de agente que se ejecute más tiempo que la duración del token—, el cliente usa un token de actualización para obtener un nuevo token de acceso sin requerir que el usuario vuelva a dar consentimiento de forma interactiva. La autorización inicial requiere presencia y consentimiento del usuario. Las actualizaciones posteriores de tokens en la misma sesión no. Este es el modelo correcto para flujos de agentes de IA que pueden ejecutarse durante periodos prolongados.
Una nota práctica de configuración: si ejecuta sesiones de agentes que pueden durar horas, la duración del token de acceso requiere una reflexión deliberada. Si es demasiado corta, estará actualizando constantemente, añadiendo latencia y superficie de fallo. Si es demasiado larga, habrá debilitado la reducción del radio de impacto que la especificación pretende ofrecer. Empezar con una duración de token de acceso de 15 a 30 minutos y actualizarlo según sea necesario es una configuración inicial razonable; ajústela según los requisitos específicos de duración de sus sesiones, no como una regla fija.
La autenticación y la autorización en MCP no son el mismo problema
Sigo viendo que se confunden estos dos conceptos, y esto produce un tipo específico de fallo en producción particularmente molesto de depurar porque el sistema parece funcionar correctamente desde fuera.
La autenticación responde: ¿quién es este cliente MCP? El servidor de autorización se ocupa de esto. Verifica la identidad del cliente y del usuario final, confirma las credenciales y declara esa identidad en el token que emite. Cuando la autenticación tiene éxito, usted sabe quién realiza la solicitud.
La autorización responde: ¿qué puede hacer esta identidad? El servidor MCP se ocupa de esto. Toma la identidad autenticada del token, lee las reclamaciones de ámbito y decide si este cliente específico con estos ámbitos específicos tiene permiso para invocar esta herramienta MCP específica en este momento. Las capacidades de autorización se aplican a nivel del servidor, no a nivel de emisión del token.
El modo de fallo que aparece en la práctica: un equipo implementa correctamente la autenticación, verifica que el cliente recibe un token válido y luego no implementa la aplicación de ámbitos en el servidor. La autenticación parece correcta. La conexión funciona. Ahora, todas las herramientas del servidor son accesibles para cualquier cliente autenticado, independientemente de qué ámbitos se hayan concedido. Esto no es un caso límite. Es la brecha de autorización de MCP más común que veo descrita cuando los equipos informan de problemas de seguridad después de la implementación inicial.
La especificación gestiona ambos mediante mecanismos de autorización distintos que deben implementarse individualmente. Un cliente MCP que recibe un token ha sido autenticado. Lo que ese token le permite hacer depende completamente de lo que el servidor MCP aplique al validar las reclamaciones de ámbito y audiencia del token. Un token válido no es un cheque en blanco. Cada invocación de herramienta necesita una comprobación de ámbito detrás.
Ahí es donde suele empezar la incidencia.
🤔 Espere.
La especificación MCP marca la autorización como opcional a nivel de protocolo. Pero cualquier servidor MCP remoto basado en HTTP expuesto a clientes no confiables sin capa de autorización acepta solicitudes de cualquiera que pueda alcanzarlo. «Opcional» aquí significa que el protocolo funcionará sin ella. No significa que la implementación sea segura sin ella. Interprete la designación de opcionalidad de la especificación como un mínimo de conectividad, no como una base de seguridad.
Dónde se queda corta la especificación de autorización de MCP para entornos empresariales
La especificación base de autorización de MCP hace lo que dice que hace. El problema es que lo que dice que hace no es lo mismo que necesitan los equipos de seguridad empresarial. No es una queja sobre proveedores. Es una brecha arquitectónica entre lo que define la especificación de MCP y lo que realmente requieren los entornos IAM de las grandes organizaciones.
El modelo actual de autorización MCP está diseñado en torno a OAuth 2.1 como mecanismo independiente. Gestiona correctamente el flujo de tokens de cliente a servidor. Lo que no define es cómo se integra ese flujo con la infraestructura de identidad empresarial existente: Microsoft Entra, Okta, IdP internos respaldados por LDAP, federación SAML o cualquiera de los otros sistemas de identidad en torno a los cuales los equipos de seguridad empresarial han dedicado años a construir la aplicación de políticas.
Las versiones actuales de la especificación de autorización de MCP asumen que usted opera un servidor de autorización independiente o que resolverá por su cuenta la integración con el IdP. Para una startup de 15 personas que lanza su primer servidor MCP, está bien. Para una organización donde cada evento de autenticación debe pasar por un proveedor de identidad centralizado, cumplir con las políticas de SSO y generar eventos de auditoría en un SIEM, la especificación base le proporciona la capa de transporte y deja la capa de políticas de nivel empresarial como ejercicio para el lector.
La comunidad MCP está debatiendo activamente esta brecha. La guía de ciberseguridad de la NSA sobre MCP advierte explícitamente que actualmente MCP carece de soporte para intercambiar permisos de control de acceso basado en roles durante la instanciación, lo que dificulta aplicar o verificar los límites de acceso entre tareas en implementaciones complejas. Es una brecha significativa si su postura de seguridad de MCP depende de RBAC que se resuelve en tiempo de ejecución en lugar de durante la emisión de tokens.
Los equipos que planean implementar servidores MCP a escala empresarial deben tratar la especificación como una base y planificar trabajo arquitectónico adicional sobre ella, no considerarla una solución completa. Una implementación compatible con la especificación no implica automáticamente una implementación preparada para la empresa.
Integración de proveedores de identidad existentes con el modelo de autorización de MCP
La brecha específica para los equipos de IAM empresarial está entre lo que define la especificación —un rol abstracto de servidor de autorización— y lo que realmente operan —un IdP concreto como Entra ID u Okta con relaciones de federación, membresías de grupo y puntos de aplicación de políticas existentes—.
La especificación permite que cualquier servicio compatible con OAuth 2.1 actúe como servidor de autorización. En teoría, Entra ID u Okta pueden desempeñar ese papel. En la práctica, conseguir que los clientes MCP descubran e interactúen correctamente con los IdP empresariales requiere trabajo de configuración sobre el que la especificación no ofrece orientación, especialmente en torno a cómo los metadatos de recursos protegidos se asignan a endpoints de autorización específicos del IdP y cómo los ámbitos se alinean con las estructuras de roles empresariales.
El riesgo de implementar MCP con un servidor de autorización independiente en lugar de integrarlo con el IdP existente: se crea un segundo silo de identidad. El acceso a herramientas MCP pasa a regirse por políticas que existen fuera del sistema IAM empresarial, se gestionan por separado, se auditan por separado y no están inscritas en los procesos centrales de gobernanza de identidad.
La autorización externa mediante servicios de autorización de terceros, o una integración estrecha entre la capa de autorización MCP y los IdP internos existentes, es la dirección recomendada para los entornos empresariales. La gestión de autorización vinculada a un servidor de autorización MCP independiente del que nadie en el equipo de seguridad tiene visibilidad es exactamente el tipo de almacén de credenciales oculto que los equipos de seguridad empresarial dedican tiempo a eliminar. Implementar MCP correctamente a escala empresarial implica resolver deliberadamente este problema de integración con el IdP, no esperar que se resuelva solo.
Por qué proteger MCP para identidades de agentes no humanos es un problema más difícil
El flujo de código de autorización OAuth 2.1 presupone que hay una persona presente para autenticarse y dar consentimiento. Los agentes de IA y las canalizaciones automatizadas no tienen ese privilegio. Un agente que necesita llamar a un servidor MCP a las 3 de la madrugada en medio de un flujo no puede redirigir un navegador y esperar a que alguien haga clic en «Permitir».
Esta es la brecha que deja abierta la especificación. El análisis de Aembit sobre la especificación identifica la autenticación sólida de agentes y la identidad afirmada por la infraestructura como el patrón necesario para cubrirla. La idea es que, en lugar de requerir consentimiento interactivo para agentes no humanos, la infraestructura afirma la identidad basándose en atributos verificables de la propia carga de trabajo. La identidad del agente proviene de dónde se ejecuta, no de credenciales que posee y que podrían filtrarse.
Un servidor MCP puede usar patrones de autorización específicos para flujos de máquina a máquina, incluido el flujo de credenciales de cliente OAuth 2.1 para escenarios no interactivos. Sin embargo, esto requiere una gestión cuidadosa de credenciales: los servidores MCP actúan como clientes OAuth en esta configuración, y las credenciales emitidas para el acceso de máquina a máquina necesitan políticas de rotación, restricciones de ámbito y procedimientos de revocación que la especificación no prescribe. La complejidad de autenticación para identidades no humanas no desaparece con la elección del protocolo. Simplemente se traslada a otro lugar. Proteger MCP para canalizaciones automatizadas que no pueden realizar consentimiento interactivo es el problema de implementación que los equipos que resuelven la especificación base deben volver a resolver desde cero cuando introducen flujos agénticos.
Buenas prácticas de autorización de MCP que realmente previenen los fallos comunes
Cada elemento a continuación identifica un modo de fallo específico y la comprobación o decisión de diseño que lo evita. No son recomendaciones de seguridad genéricas. Se basan en lo que exige la especificación y en lo que se rompe cuando los equipos omiten pasos.
Aplique la validación de tokens por solicitud; nunca reutilice la confianza basada en sesiones
La especificación lo exige. El modo de fallo es un equipo familiarizado con aplicaciones web basadas en sesiones que almacena en caché «este cliente fue autorizado hace cinco minutos» y omite la validación posterior. Cuando el token se revoca o caduca, el servidor MCP sigue aceptando solicitudes hasta que se borra la caché. Valide el token en cada llamada al servidor MCP, no una sola vez al inicio de la sesión.
Implemente la aplicación de ámbitos a nivel de herramienta, no solo en el momento de conexión
Un token con autenticación válida pero sin ámbitos específicos de herramienta debe rechazarse en el punto de invocación de la herramienta. El error común: comprobar que el token es válido, confirmar que el cliente se conectó y después permitir cualquier llamada a una herramienta. Los servidores MCP deben implementar comprobaciones de ámbito frente a la herramienta específica invocada en cada solicitud. Un token limitado a lectura no debería poder llamar a una herramienta de escritura, aunque la conexión se haya realizado correctamente.
Admite el registro dinámico de clientes mediante RFC 7591
Los clientes MCP deben admitir el registro programático en lugar de requerir que todos los clientes se registren manualmente con antelación. El modo de fallo sin esto: no puede incorporar nuevos clientes de agentes a escala sin un paso de configuración manual por cliente. Permita que los clientes MCP se registren dinámicamente y asegúrese de que los clientes registrados dinámicamente reciban ámbitos adecuadamente restringidos en lugar de acceso general.
Exija PKCE para todos los flujos de código de autorización, sin excepciones
Omita PKCE en un flujo que hoy parezca «seguro» y dejará abierta una vía de interceptación de códigos de autorización. La especificación exige PKCE para clientes públicos. Trátelo como un requisito universal en lugar de evaluarlo caso por caso. Todo nuevo flujo de autorización añadido a su implementación debe incluir PKCE de forma predeterminada.
Transmita los tokens en el encabezado Authorization, no en el cuerpo de la solicitud ni en la cadena de consulta
Este es un punto básico de higiene de transporte que se omite más de lo debido. Un token de acceso en una cadena de consulta aparece en registros del servidor, historial del navegador y encabezados de referencia. En el encabezado, no. Toda implementación de cómo los clientes envían tokens al servidor MCP debe comprobar que el encabezado sea el mecanismo de entrega.
La autorización de MCP no sustituye los controles de acceso de las API posteriores
Este es el malentendido más costoso que veo en la forma en que los equipos razonan sobre su postura de seguridad después de implementar la autorización de MCP. La autorización de MCP controla el acceso al servidor MCP y sus herramientas. Los servicios de respaldo a los que llaman esas herramientas —sus API internas, bases de datos y sistemas SaaS— todavía necesitan sus propios controles de acceso. Un token que autoriza una invocación de herramienta en la capa MCP no autoriza todo lo que esa herramienta pueda hacer posteriormente. La capa principal de autorización MCP y la autorización de servicios posteriores son puntos de aplicación independientes que deben implementarse individualmente. Los equipos que implementan la capa MCP y se declaran seguros tienen una sorpresa poco agradable esperándoles.
Utilice tokens de actualización para sesiones de agentes de larga duración, con rotación
La caducidad de un token de acceso durante un flujo de agente de varios pasos es un fallo de fiabilidad que los equipos encuentran pronto. La arquitectura correcta: emitir un token de actualización durante la autorización inicial y usarlo para obtener nuevos tokens de acceso sin interrumpir el flujo. Utilice rotación de tokens para que cada actualización invalide el token de actualización anterior, limitando el radio de impacto de un token de actualización robado.
📊 En la práctica:
La validación de tokens por solicitud frente al servidor de autorización es lo que exige la especificación, y rompe directamente el patrón común de confianza basada en sesiones que los equipos importan de la autenticación web tradicional. La comprobación de implementación es concreta: si su servidor MCP tiene alguna ruta de código en la que un token de cliente visto anteriormente omite la validación porque «ya lo comprobamos», esa ruta de código incumple la especificación y debilita su postura de seguridad al mismo tiempo. Elimínela.
Quién utiliza la autorización de MCP y qué intenta realmente controlar
Tres tipos de equipos se encuentran con problemas de autorización de MCP en la práctica, y cada uno intenta controlar algo distinto.
Los equipos de plataformas de IA que crean herramientas para que las llamen los agentes intentan principalmente controlar qué clientes MCP pueden acceder a qué herramientas mediante ámbitos y roles. El primer servidor MCP que implementan suele comenzar sin controles de ámbito más allá de «autenticado o no». El problema surge cuando necesitan permitir que un agente de analítica de solo lectura vea las salidas de las herramientas, pero impedirle llamar a operaciones de escritura. El flujo de código de autorización con un diseño adecuado de ámbitos resuelve esto, pero requiere pensar en la taxonomía de ámbitos antes de crear el servidor, no después. La especificación MCP proporciona el mecanismo. Usted debe definir los ámbitos que vale la pena aplicar.
Los equipos de seguridad e IAM intentan centralizar las políticas para no gestionar un almacén de credenciales independiente por cada implementación de MCP. Su objetivo es la integración de IdP OAuth 2.1: cada token MCP debería poder rastrearse hasta un evento de identidad en el proveedor central de identidad, no en un servidor de autorización independiente. Quieren tokens de vida corta, reclamaciones claras de audiencia del servidor de recursos en cada token y la capacidad de revocar acceso revocando la sesión del IdP. Las credenciales amplias y de larga duración que no están incluidas en la gobernanza central de IAM son exactamente lo que intentan eliminar. La autorización de MCP les proporciona el patrón. Conseguir que se federen con su IdP existente es el trabajo de implementación.
Los proveedores SaaS y de infraestructura que exponen servidores MCP a clientes externos necesitan integración de SSO empresarial y configuración automatizada de clientes mediante metadatos de ubicación del servidor de autorización. Los agentes de sus clientes deben descubrir el servidor de autorización, registrarse dinámicamente y obtener tokens con ámbitos adecuados, todo ello sin un paso de incorporación manual por cliente. RFC 8414 y RFC 9728 no son dependencias teóricas para este caso de uso. Son el mecanismo que hace posible la incorporación programática. Sin ellas, cada nuevo cliente exige una configuración manual.
Para los equipos que crean flujos de automatización sobre servidores autorizados por MCP, el mismo modelo de tokens y ámbitos se aplica dentro de la implementación. Un flujo que escucha respuestas 401 de servidores MCP, dirige centralmente el intercambio OAuth 2.1 + PKCE y realiza llamadas con el token resultante es un patrón más limpio que integrar la gestión de autenticación en cada integración individual. Latenode admite esto mediante nodos JavaScript que pueden gestionar la lógica de intercambio de tokens y sus más de 5.500 integraciones con OAuth automático para las conexiones de servicios subyacentes: el tipo de configuración que transforma un proyecto de autenticación de varias semanas en algo que se implementa en una tarde, una vez que ha modelado el flujo una sola vez.
