OAuth sin intervención para MCP

• La extensión Enterprise-Managed Authorization (EMA) se estabilizó, permitiendo a las empresas gestionar centralmente los permisos de los servidores MCP y a los usuarios iniciar sesión una sola vez para acceder a los servidores autorizados
• El enfoque anterior dependía de la aprobación individual de OAuth por usuario y por servidor, lo que dificultaba el onboarding, la aplicación de políticas de seguridad, la trazabilidad de auditoría y la separación entre cuentas de trabajo y personales
• EMA coloca al IdP de la organización como la autoridad que decide los permisos, de modo que el administrador define la política una sola vez y los usuarios heredan las conexiones MCP necesarias con su cuenta organizacional existente
• El ID-JAG emitido durante el SSO se intercambia por un token de acceso en el servidor de autorización del servidor MCP, por lo que el usuario no es redirigido a una pantalla de consentimiento por cada servidor
• El soporte inicial incluye a Okta, Anthropic, Visual Studio Code y también a Asana, Atlassian, Canva, Figma, Granola, Linear y Supabase; Slack también está agregando soporte

---

Estabilización de EMA y objetivo de despliegue empresarial

• La extensión Enterprise-Managed Authorization (EMA) pasó a estado stable
• Al gestionar conexiones a servidores MCP en entornos empresariales, las aprobaciones repetidas y los prompts de consentimiento eran una molestia importante, y EMA es una extensión creada para reducir ese problema
• Las organizaciones pueden controlar centralmente el acceso a servidores MCP mediante un proveedor de identidad (IdP) de confianza
• Los usuarios finales inician sesión con su cuenta organizacional existente y luego se conectan a los servidores MCP autorizados, reduciendo la carga de consentimientos OAuth por servidor o configuraciones únicas

Límites del modelo de autenticación por usuario

• El modelo estándar de permisos de MCP está diseñado para un alcance por usuario (user-scoped) y para las convenciones tradicionales de autenticación interactiva
• Puede funcionar para escenarios de consumo donde cada persona decide directamente a qué datos accede, pero no escala bien en despliegues empresariales
• En entornos empresariales destacan especialmente tres problemas
  • Cada empleado debe aprobar cada servidor por separado, por lo que durante el onboarding se requieren conexiones manuales por servicio
  • Los equipos de seguridad terminan dependiendo de accesos aprobados por cada usuario sin control central ni trazabilidad de auditoría
  • Es difícil imponer el uso de cuentas corporativas, por lo que los usuarios pueden conectar cuentas personales a herramientas de trabajo
• Esta fricción retrasa la adopción de MCP y aumenta la posibilidad de crear implementaciones alternativas frágiles
• Sin un estándar general para conservar un estado de autenticación compartido, cada implementador termina creando su propia solución, y aun con datos y herramientas disponibles, gran parte puede quedar desactivada por el costo de los permisos por usuario

Aprobar una vez y heredar en todas partes

• Enterprise-Managed Authorization convierte al IdP de la organización en la autoridad que decide el acceso a servidores MCP
• El administrador define la política una sola vez, y los usuarios se autentican en el host MCP con su identidad organizacional existente
• El IdP puede permitir o denegar acceso según membresía de grupos, roles y reglas de acceso condicional
• El flujo interno es el siguiente
  • El cliente obtiene del IdP un Identity Assertion JWT Authorization Grant (ID-JAG) durante el SSO
  • El cliente lo envía al servidor de autorización del servidor MCP para intercambiarlo por un token de acceso
  • El usuario no pasa por una pantalla de consentimiento por servidor
• Esta estructura produce tres efectos
  • Si el administrador habilita un servidor para la organización, los usuarios obtienen acceso automáticamente dentro del alcance de sus grupos y roles existentes
  • Las decisiones de acceso quedan registradas en la consola administrativa del IdP, ofreciendo un único historial auditable para todos los conectores
  • Al eliminar el paso interactivo de selección de cuenta, resulta más fácil reducir la confusión en los flujos de datos entre cuentas personales y corporativas
• En el uso empresarial de MCP, el objetivo es que, cuando el usuario inicie sesión, el cliente se conecte a las herramientas y datos autorizados sin pasos adicionales

Productos con soporte inicial y ecosistema

• En este lanzamiento participan en la implementación tres grupos: proveedores de identidad, clientes y servidores

• Proveedores de identidad

  • Okta es el primer proveedor de identidad compatible
  • Las organizaciones que usan Okta pueden aprovisionar acceso MCP a clientes y servidores compatibles mediante Okta’s Cross App Access (XAA)

• Clientes

  • Anthropic implementó EMA en la capa compartida de MCP de Claude
  • Los administradores pueden aprobar servidores MCP para usuarios en Claude, Claude Code y Cowork
  • Visual Studio Code también añadió soporte para EMA dentro del IDE

• Servidores

  • Asana, Atlassian, Canva, Figma, Granola, Linear y Supabase son compatibles con EMA
  • Slack y otros servidores también están agregando soporte
  • Aaron Parecki, de Okta, afirma que integrar el protocolo Cross App Access en la extensión EMA de MCP convierte la identidad en un plano central de gobernanza, ofreciendo a los equipos de seguridad controles de cumplimiento y a los usuarios una experiencia fluida
  • Devdatta Akhawe, de Figma, afirma que, a medida que aumenta la adopción de MCP, XAA facilita escalar con seguridad los despliegues empresariales de MCP
  • Tom Moor, de Linear, mencionó la experiencia de iniciar sesión una vez y que todos los conectores MCP queden configurados automáticamente

Documentación y canales de participación

• Los clientes, servidores y plataformas de identidad pueden revisar la especificación de la extensión y agregar soporte para el nuevo estándar en sus productos
• La página de Enterprise-Managed Authorization documenta los requisitos de flujo para clientes, servidores y servidores de autorización
• En el repositorio ext-auth y el borrador de la especificación se pueden consultar los cambios más recientes y materiales de apoyo de EMA
• El EMA Interest Group se utiliza para discutir la extensión, reportar compatibilidad e impulsar mejoras iterativas
• EMA es un trabajo de la comunidad MCP, con contribuciones de los autores de SEP-990, mantenedores del repositorio ext-auth y proveedores de identidad y de MCP que probaron las implementaciones iniciales e impulsaron la especificación

[GN⁺]

Comentarios de Hacker News

• Antes de caer en el típico debate de “MCP murió y Skills es el futuro”, el punto donde MCP realmente aporta valor frente a skills/CLI es que separa el flujo de autenticación de la ventana de contexto del agente y, en algunos casos, incluso fuera del harness
  Desde la perspectiva de seguridad eso obviamente es importante, y también hace que la experiencia de uso sea mucho más sencilla cuando usuarios comunes o grandes empresas adoptan herramientas de IA
  Entiendo las quejas sobre el crecimiento del contexto o la duplicación en las llamadas a herramientas, pero claramente hay valor en una arquitectura que maneja la autenticación de esta manera
  Un MCP ideal podría ya ser suficientemente beneficioso aunque solo fuera una pasarela de autenticación delante de una API

  • Esta extensión también muestra bien otras ventajas de MCP frente a skills: control centralizado, facilidad de uso para empleados, auditoría/compliance y modelo de despliegue
    En este momento, lo mejor que parece existir para desplegar skills es algo como “copia este archivo y ponlo aquí”, “haz checkout de este repositorio y agrega un enlace simbólico”, o “instálalo con un comando slash”
    Aunque sea simple, no resulta tan fácil como esta forma de extensión para desplegar un nuevo servidor MCP a los empleados
  • MCP también permite un excelente rastro de auditoría
    Por ejemplo, podrías autenticar 6 cuentas de Linear de 6 clientes distintos, y luego habilitar una separación de responsabilidades donde se elige qué cuenta usar de forma determinista y auditable
  • La verdadera lección es que MCP vs. skills no es una dicotomía
    Simplemente son herramientas diferentes, y según los requisitos una puede ser mejor o no
    Es como preguntar qué es mejor, un cuchillo o una sierra
  • Además, MCP permite conectar plataformas externas sin entorno de ejecución
    Cada vez que sale este tema, los ingenieros tratan a Claude Code como si fuera la única app de agentes de IA, pero hay muchísimos casos de uso en otros sectores además de programación
    El harness puede ejecutarse no en una máquina local, sino en un contenedor aislado y restringido en la nube, donde ejecutar código arbitrario nunca está permitido
    Aun así, cuando el cliente quiere conectar sus herramientas existentes al agente, MCP encaja perfecto porque ofrece conectores con autenticación integrada, y skills no aplica en ese terreno
  • Estoy creando una plataforma para hacer reseñas de restaurantes con amigos y, después de varios intentos y errores, parece que MCP va en la dirección correcta
    Un usuario común no va a buscar el directorio de Claude para pegar ahí un archivo de skill
    “Connections” es fácil de entender, y es más sencillo pegar un MCP o encontrarlo en un marketplace
    Todavía no está claro si realmente será útil que un agente tenga acceso a lugares y reseñas

• Muchas felicitaciones a quienes construyeron esto en Okta, Anthropic, Microsoft, Figma, Linear y otras empresas
  Incluso para los escépticos de MCP hay algo aprovechable aquí
  Esto funciona con un nuevo formato de token llamado ID-JAG, disponible en https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
  No es en absoluto exclusivo de MCP, y cualquier lugar donde aplicaciones que usan el mismo proveedor de SSO necesiten compartir datos de forma segura puede usar ID-JAG

  • Estas empresas han empeorado el software y la calidad de vida, así que da una sensación de cinismo pensar que realmente haya algo que felicitar

• Estoy intentando agregar autenticación con Microsoft Entra ID al servidor MCP que estoy implementando ahora mismo y, sinceramente, siento que me volví idiota
  Con el encabezado WWW-Authenticate puedes indicarle al cliente la URL de metadatos del recurso, y mediante eso también se puede especificar Microsoft Entra como servidor de autenticación y el alcance del registro de la app
  Pero no se puede especificar el client_id, y la idea es que cada cliente, es decir, cada agente, lo genere por su cuenta
  Para iniciar sesión con la URL .../authorize de Microsoft Entra hace falta un client_id conocido que coincida con el registro de la app en Entra, y no hay forma de que un valor inventado arbitrariamente por el cliente coincida con Entra
  En teoría se podría soportar el registro dinámico de clientes, pero Microsoft Entra obviamente no lo soporta
  Al final, la única salida que veo es crear mi propio shim de registro dinámico de clientes delante de Microsoft Entra para devolverle a todo el mundo el mismo client_id estático
  Siento que me estoy perdiendo algo obvio sobre si este protocolo realmente funciona en entornos empresariales sin hacer rodeos

  • No parece que te estés perdiendo nada obvio
    Entra ID no soporta registro dinámico de clientes y el estado de este ecosistema todavía no es bueno
    Normalmente el OAuth de MCP se maneja con clientes tradicionales preregistrados, pero en la práctica muchos clientes MCP asumen que existe registro dinámico de clientes y no ofrecen una opción para especificar el client_id
    Aun así, algunos clientes sí lo soportan y, ya que estamos haciendo algo de autopromoción, nuestra herramienta Erato también lo soporta: https://erato.chat/docs
    Las soluciones empresariales típicas que se despliegan también suelen centralizar el acceso a MCP mediante una UI web, así que soportan esto
    Otra alternativa es un gateway MCP; entre el gateway y el servicio puedes usar OAuth preregistrado, y entre el gateway y el cliente puedes permitir registro dinámico de clientes
  • Nosotros también tuvimos el mismo problema por el client_id y no queríamos habilitar el registro dinámico de clientes por razones de seguridad
    Al final hicimos que la app actuara como proxy del flujo OAuth e inyectara un client_id hardcodeado
    Le haces creer al cliente MCP que soportas registro dinámico de clientes, pero internamente usas un client_id independiente para MCP como de costumbre
    Hay un ejemplo aquí: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
  • Justo lo implementé ayer, y la idea es que esta biblioteca ejecuta el servidor MCP: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
    Después creé una aplicación intermediaria de autenticación que maneja el registro del cliente con OpenID y genera los JWT
    Como resultado, ahora puedes decidir si alguien puede usar una herramienta y con qué permisos según el departamento del empleado u otros criterios
    Al final sí se necesita registro dinámico de clientes
  • Hace poco, en FusionAuth documentaron cómo usar clientes preregistrados: https://fusionauth.io/docs/extend/examples/controlling-acces...
    También están evaluando y discutiendo activamente CIMD, un hermano más nuevo y mejor de DCR, pero todavía no está disponible: https://github.com/FusionAuth/fusionauth-issues/issues/3230
    Como alternativa al proxy que propusiste, se puede crear un nuevo client_id de Entra con PKCE habilitado para cada cliente MCP desde algo como un portal para desarrolladores, y hacer que el usuario configure ese valor en el cliente
    Encontré el comando de CLI para eso aquí, y supongo que también habrá una API: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
    La configuración de Claude Code está en https://code.claude.com/docs/en/mcp y la de ChatGPT en https://developers.openai.com/api/docs/guides/developer-mode
    El preregistro de clientes puede no ser lo ideal para los desarrolladores, pero es aceptable, y en la especificación también se trata como un enfoque de primera clase: https://modelcontextprotocol.io/specification/2025-11-25/bas...
    Si los usuarios principales son empleados internos y pueden seguir instrucciones de configuración para acceder al servidor MCP, este enfoque también funciona
    Pero si el objetivo es una integración pública amplia para gente que no es desarrolladora, claramente no es algo aceptable, y justamente ahí es donde está gran parte de la fuerza y la oportunidad de MCP

• Soy una de las personas que construyó esto en Anthropic junto con Okta y varios socios de MCP.
  Me entusiasma mucho ver que este formato va tomando forma en Claude y, ahora que en la especificación de MCP EMA es una extensión estable, también me gustaría ampliar su adopción a otros proveedores de identidad y clientes.
  Si tienen comentarios, sería genial que los dejaran aquí; siempre queremos escuchar experiencias reales de uso y cómo podríamos mejorarlo.

  • Qué gusto verte de nuevo.
    Hace tiempo que no seguía de cerca MCP, pero esto parece encajar bastante bien para hacer que MCP sea más seguro dentro de las organizaciones y para resolver las debilidades del registro dinámico de clientes.
    Ahora tanto el proveedor de identidad como la organización pueden configurar directamente los clientes y los URI de redirección autorizados, así que se pueden mitigar más ampliamente ataques basados en DCR, como confused deputy o phishing.
    Además, también es una gran ventaja porque reduce la lógica de autorización que antes tenía que implementar el servidor MCP cuando el proveedor de identidad o la organización no soportaban DCR.
    La desventaja es que, para uso de consumidores, todavía parece que sigue siendo necesario DCR.
    Tal vez se podría resolver si proveedores OAuth de consumo como GitHub, GitLab y Google soportaran registro estático de cliente/servidor MCP, si el cliente integrara un client_id estático y si el usuario iniciara sesión con ese proveedor de identidad y administrara directamente la conexión.
    En general, XAA/EMA parece muy superior a DCR en seguridad y usabilidad.
    Incluso las partes preocupantes son mucho más fáciles de resolver y tienen un impacto de seguridad menor que en DCR, porque un atacante no puede registrar su propio cliente y también se reducen las trampas en las que puede caer quien desarrolla el servidor MCP.
  • Es excelente para las “apps” en general, pero para nosotros es urgente tener una forma de interactuar de manera tipo agente con menos fricción, sin que el usuario tenga que configurar MCP.
    Sería bueno tener algún tipo de sesión temporal o almacén de tokens fuera de banda.
    El caso de uso es que, durante el proceso comercial, compradores y vendedores tienen que intercambiar y analizar mucha información, y ese análisis se está volviendo cada vez más agentivo.
    El problema con MCP es que la fricción de configuración inicial es mucho mayor que simplemente hacer que el usuario inicie sesión directamente y traiga la información necesaria.
    MCP funciona bien para interacciones regulares y frecuentes, pero tiene muchos problemas para sesiones rápidas de una sola vez.
    Estaría bueno que en Claude uno pudiera decir “trae documentos de X, Y y Z”, que Claude accediera a esos sitios web y que el sitio devolviera información básica del usuario junto con un enlace de inicio de sesión que el usuario pudiera abrir en el navegador.
    Luego el usuario se autentica en el navegador, el callback devuelve un token único de un solo uso y de vida corta, y después ese token se intercambia en las solicitudes al sitio.
    Así se podría autenticar rápidamente al usuario y al mismo tiempo mantener el estado de la sesión durante el trabajo.
  • Me da curiosidad si están en contacto con el equipo de Microsoft Entra, o sea Azure AD.
    Quisiera saber si es razonable esperarlo pronto o si todavía va a tomar bastante tiempo.
  • Felicitaciones por el lanzamiento.
    Parece que el caso de uso principal son empleados de empresas, pero me pregunto si hay un valor parecido también para usuarios no centralizados, como clientes o usuarios free premium.
    No se me ocurre mucho, así que quería saber qué me estoy perdiendo, y creo que vi una respuesta relacionada aquí: https://news.ycombinator.com/item?id=48594381
  • Quiero confirmar si esto todavía no se puede usar realmente y si sigue en etapa SEP.

• Esto es realmente excelente.
  En los últimos meses tuve la suerte de poder trabajar con gente de MCP en varios SEP y en un SDK experimental de Go.
  Antes yo era de los escépticos que decían “si al final solo es una API” o “ya inventaron otra abstracción”.
  Lo que la gente pasa por alto es que la “P” de MCP lleva a malentendidos.
  Cuando haces una app tradicional, tienes que construir formularios, UI, manejo de request/response, canales bidireccionales, trabajos de larga duración, autenticación, etc.
  Con MCP, el 80% de esa capa común ya está resuelta, así que MCP es un protocolo, sí, pero en la práctica también se parece mucho a un framework de aplicaciones.
  La autenticación integrada es un refuerzo enorme, y entusiasma pensar en todo lo que viene.

• Es bastante curioso ver afuera algo en lo que trabajé.
  En Atlassian me encargué de la implementación del lado RAS de este flujo.
  Claramente habrá mejoras iterativas en este flujo, como CIMD y mejor soporte de tenancy.
  Toda la gente de Anthropic, Okta y Atlassian que llevó esto adelante fue excelente.

• Estaría bueno que soportaran la web para poder simplemente emitir cookies de larga duración.
  Traté de hacer esto sin servidor OAuth y terminé hackeando la especificación para pasar cookies mediante el handshake de OAuth.
  Es realmente frustrante que no quieran permitir algo así.
  Si no hay cookie, abres la página web; cuando la cookie queda configurada, la cierras y la guardas.
  Incluso escribí un minibook de 80 páginas sobre MCP, pero igual me sigue frustrando sin parar.

  • Soy uno de los maintainers principales del proyecto MCP, y este enfoque no escala en varios escenarios.
    Tiene problemas tanto de usabilidad como de seguridad, y las cookies fueron hechas para navegadores.
    Los servidores y clientes MCP muchas veces operan en entornos donde no hay garantía de navegador.
  • Eso es casi como pedir que te dejen robar credenciales.
    Las credenciales de larga duración implican una carga de responsabilidad enorme.

• Lo releí varias veces y sin duda es útil.
  Se puede centralizar la auditoría y el control de acceso en un solo proveedor de identidad, y ese proveedor también podría actuar como una API gateway proxy que se encarga del intercambio de tokens cuando haga falta.
  Es un enfoque que también han adoptado otros actores de este espacio.
  En lo personal, me incomoda un poco que el proveedor de identidad delegue mis permisos a un cliente sin que yo lo advierta.
  Tal vez sea porque estoy demasiado acostumbrado a flujos donde el usuario está presente en el navegador, y esto se siente como una evolución hacia una centralización del acceso cada vez más pensada para máquinas.
  En entornos enterprise puede ser aceptable, porque la identidad pertenece más a la empresa que al individuo.
  Pero integrarlo en customer identity ya es un desafío completamente distinto, y probablemente no sea fácil construir ese nivel de confianza entre proveedor de identidad, cliente y resource authorization server.

  • No hay una barrera teórica que impida que esta integración funcione en el ámbito de consumo.
    Por ejemplo, bastaría con crear una relación de confianza del tipo “si ya iniciaste sesión en GitHub, entonces también entras automáticamente en Sentry”.
    Todavía queda mucho por hacer, pero por ahora el caso de uso más claro es, como dijiste, el enterprise.
    Los administradores no quieren que cada empleado ande haciendo clic por todos lados y eligiendo credenciales arbitrarias.

• En C1, la autenticación de MCP era un gran dolor de cabeza tanto para el uso interno de MCP como para el MCP Gateway dentro del producto, así que da muchísimo gusto ver que esto llegue
  Hoy C1 lanzó soporte para actuar como proveedor de identidad EMA y emitir tokens de alcance limitado con vida corta
  Ahora quiero conectarlo a Linear y a los otros MCP que usamos para salir de los flujos repetitivos de OAuth
  Claude ya hacía algo así casi como por arte de magia con algunos conectores integrados, al menos en Slack, y la experiencia era bastante buena
  Para transparentar, soy VPE de C1, y documentamos nuestro enfoque para quien quiera profundizar: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

• No me queda muy claro qué ventaja tiene esto frente a OAuth normal
  Creo que haría falta un ejemplo comparando los flujos de autorización

  • En OAuth normal, el usuario final da su consentimiento individualmente para que cada aplicación comparta sus datos
    Eso tiene sentido en casos de uso de consumo, es decir, cuando el usuario final es dueño de sus datos
    Pero en muchos casos de uso empresariales, quien debe compartir los datos y controlar el acceso no es el usuario final, sino la empresa
    Si yo soy empleado de Acme, no debería decidir si los datos de Google Drive de Acme se conectan a Claude o ChatGPT; eso debería decidirlo el área de TI
    OAuth administrado por la empresa, o Cross App Access (XAA), incorpora al framework de OAuth un modelo de compartición controlado centralmente por administradores de TI, para que funcione junto con el ecosistema existente
    Además, mover la gestión del consentimiento para compartir datos del empleado al administrador de TI también trae una gran ventaja en la experiencia de usuario
    El empleado no tiene que pasar por múltiples flujos de OAuth para conectar cuentas, porque el administrador de TI ya dejó configurados los controles de compartición
    Piensa en llegar en tu primer día y que Slack ya esté conectado a Zoom, Drive, Calendar, etc.
  • La ventaja es que los usuarios no necesitan controlar ni dar consentimiento sobre qué apps están autorizadas a compartir su información entre sí
    Porque la decisión de delegar acceso se toma a nivel de política del proveedor de identidad
    Puede que los usuarios nunca sepan qué apps o servicios quedaron autorizados para compartir su información
    Espera, ¿de verdad eso es una ventaja? ;-)