Okta, Auth0 y Descope convergen en el mismo patrón de acceso para agentes de IA en ocho días

Entre el 24 de agosto y el 1 de septiembre de 2026, tres proveedores de identidad que compiten directamente por los mismos clientes empresariales —Okta, Auth0 y Descope— lanzaron, cada uno por su cuenta, el mismo patrón de acceso para agentes de IA conocido como Cross App Access (XAA). El orden de los anuncios importa menos que el hecho de que los tres implementaron la misma combinación de dos especificaciones técnicas, lo que sugiere que el sector ha encontrado un estándar de facto para un problema que hasta ahora se resolvía con parches: cómo permite una empresa que un agente acceda, en nombre de un usuario, a aplicaciones y servidores MCP de terceros sin recurrir a claves de API compartidas y de larga duración.

El 24 de agosto, Okta llevó "Agent SSO" a disponibilidad general, integrando Cross App Access dentro de su producto de identidad principal, el mismo que —según la propia compañía— usan más de 20.000 clientes. La función se incluye sin coste adicional en los planes de SSO existentes, mientras que un paquete más amplio, "Okta for AI Agents", se vende por separado. Okta describe el alcance de Agent SSO de forma deliberadamente estrecha: resolver cómo los agentes que usan Cross App Access se conectan a aplicaciones empresariales y servidores MCP. Su Integration Network ya ofrece soporte listo para usar con Anthropic (Claude), Archestra.AI, Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, MintMCP, Notion, Slack y Supabase.

Una semana después, el 31 de agosto, Auth0 completó su propia implementación. Ya había abierto en acceso temprano, el 27 de julio, el lado de "aplicación de recurso" (la API que acepta credenciales emitidas por otro sistema); con el lanzamiento de finales de agosto sacó de fase beta también el rol de "aplicación solicitante", el que pide la credencial en nombre del usuario. El sistema corre sobre Auth0 Token Vault y el protocolo ID-JAG: en el lado solicitante funciona hoy sobre conexiones OIDC y Okta Workforce, y en el lado de recurso acepta tanto proveedores empresariales SAML como OIDC.

Descope cerró la semana, el 1 de septiembre, anunciando soporte simultáneo para validación y emisión de tokens ID-JAG. A diferencia de los otros dos, su lanzamiento apunta explícitamente a equipos de software B2B: añade una configuración de autoservicio de XAA a la misma suite que ya incluye SSO, SCIM y aprovisionamiento just-in-time, de modo que el administrador de un cliente empresarial puede elegir su proveedor de identidad, establecer emisores de confianza, registrar agentes y mapear atributos de usuario mediante un asistente guiado. Rishi Bhargava, cofundador de Descope, resumió en el propio comunicado la presión que reciben las empresas que operan servidores MCP: cada compañía B2B que publica uno está a punto de escuchar la misma pregunta de sus clientes empresariales sobre si pueden gobernar el acceso de los agentes con su propio proveedor de identidad.

Debajo de los tres anuncios hay una arquitectura común de dos capas que resuelve dos problemas distintos: quién es el software que llama, y quién le permite llegar a dónde. La primera capa identifica al cliente mediante un "Client ID Metadata Document" (CIMD). La especificación de MCP fechada el 28 de julio de 2026 dejó obsoleto el registro dinámico de clientes (DCR) en favor de CIMD, conservando DCR solo por compatibilidad hacia atrás. Un credential de DCR queda atado al servidor de autorización que lo emitió y hay que volver a registrarlo si ese servidor cambia; un client_id de tipo CIMD, en cambio, es una URL HTTPS autoalojada que cualquier servidor de autorización puede resolver bajo demanda, y esa portabilidad es la razón de fondo de la sustitución. En un entorno gestionado por la empresa esta capa se vuelve indispensable: el proveedor de identidad graba un client_id fijo en cada credencial, y el servidor de la aplicación tiene que reconocer ya ese identificador antes de que llegue la primera credencial, lo que descarta a un cliente que se autorregistra sobre la marcha.

Agosto fue, en la práctica, el mes de CIMD del lado de los proveedores: Okta lanzó el registro de agentes vía CIMD como versión de investigación el 5 de agosto —los administradores registran una URL, los desarrolladores controlan la autenticación en ese endpoint y Okta autentica a los agentes en tiempo de ejecución sin almacenar credenciales—; Clerk publicó su propia beta de CIMD el 6 de agosto; y Auth0 ya había incorporado el registro CIMD dentro de la disponibilidad general de "Auth for MCP" en mayo. Del lado del cliente, herramientas como VS Code, MCPJam, ChatGPT y Claude Code ya publican sus propios documentos de metadatos.

La segunda capa es la delegación, y es donde reside el control real de la empresa: el token ID-JAG. Según la propia explicación de Auth0, el proveedor de identidad actúa como punto de aplicación de la política: solo emite la credencial si la política del administrador permite que esa aplicación solicitante llegue a esa aplicación de recurso en nombre de ese usuario, y puede recortar los permisos solicitados en el camino. Las dos capas se encuentran en un único campo: en el ejemplo de Auth0, el client_id incluido dentro del ID-JAG es precisamente un identificador CIMD, aunque eso es una característica de cómo se registró ese cliente concreto, no una exigencia del protocolo en sí. La responsabilidad final sigue siendo conservadora: según el borrador de ID-JAG, el servidor de autorización del recurso conserva la potestad de emitir los tokens de acceso a sus propios recursos protegidos, y decide bajo su propia política local si honra la credencial, qué permisos concede y qué token entrega. La ventaja práctica para los equipos que construyen la API, según describe Auth0, es que esta valida el token resultante exactamente igual que cualquier otro: el código de la API no cambia y nunca llega a "enterarse" de que hubo un intercambio XAA de por medio.

El argumento obvio en contra de esta lectura es que todo esto es el protocolo de Okta disfrazado de estándar abierto. Okta lideró el diseño, es dueña de la red de integraciones donde viven los conectores, y la autenticación gestionada por empresa para conectores MCP de Anthropic alcanzó disponibilidad general el 24 de agosto con Okta como único proveedor de identidad soportado, tal y como venía siendo desde la beta de junio. Visto desde la posición de un comprador, el patrón y el catálogo de Okta pueden parecer el mismo objeto.

Los lanzamientos de esta semana matizan esa lectura. La vía de validación de Descope permite que una organización registre un emisor de confianza por cada cliente (tenant) y acepte credenciales de Okta, Ping y otros proveedores que cumplan el estándar. El lado solicitante de Auth0 funciona tanto sobre Okta Workforce como sobre conexiones OIDC genéricas. Y los propios SDK oficiales de MCP están adoptando XAA de forma nativa como la extensión "Enterprise-Managed Authorization", que es precisamente la señal de que un patrón deja de ser una característica exclusiva de un solo producto.

Conviene, eso sí, revisar los repositorios de esos SDK antes de prometerle nada a un cliente, porque la cobertura es desigual y no en la dirección que sugería la hoja de ruta original. Cuando Okta anunció el trabajo de SDK a finales de 2025, dijo que el soporte empezaría por TypeScript y Java. TypeScript, en efecto, se publicó. También lo hicieron Python y C#, este último demostrado en el propio blog de desarrolladores de Okta este verano. El PR de autorización gestionada por empresa para el SDK de Java, en cambio, se cerró sin fusionar y quedó marcado como "wontfix". Si un servidor MCP está escrito en Java, la vía nativa del SDK simplemente no existe todavía, y hay que implementar el intercambio por cuenta propia.

Las cifras que cita el propio sector explican por qué esto no es un capricho arquitectónico. Según investigación de la propia Okta, solo el 34% de las organizaciones aplica a los agentes de IA los mismos controles de seguridad que aplica a los trabajadores humanos. Descope, por su parte, cita un estudio de Gravitee de 2026 según el cual solo el 22% de los equipos trata a los agentes como identidades independientes, y la mayoría sigue apoyándose en claves de API compartidas. La alternativa a este patrón no es un patrón mejor: es la clave de API que sigue viva en un archivo .env seis meses después de que la persona que la generó abandonara la empresa.

El artículo, publicado en el blog de WorkOS, sitúa además la propia oferta de esa compañía como la pieza neutral de este ecosistema, construida antes de que la especificación se formalizara. WorkOS Connect lee client_id en formato URL, resuelve los metadatos y renderiza la pantalla de consentimiento correspondiente desde el 30 de noviembre de 2025 —bastante antes de que la especificación de MCP del 28 de julio de 2026 nombrara a CIMD como sustituto de DCR—; la función viene desactivada por defecto y se activa en el panel de Connect, en Configuración. AuthKit, por su parte, acepta en acceso temprano credenciales ID-JAG de proveedores de identidad empresariales, encargándose de la verificación de firma JWKS, la validación de audiencia y claims, la aplicación de políticas y la emisión de tokens con permisos acotados. Y auth.md, el protocolo abierto de registro de agentes que WorkOS dice haber creado, se integró dentro de AuthKit como "Agent Registration" el 4 de agosto; su implementación de referencia tiene licencia MIT y no requiere cuenta de WorkOS ni para publicar ni para leer. Nada de esto obliga a tomar partido por un proveedor de identidad concreto: es lo que se obtiene al construir contra la especificación en lugar de contra el SDK de un solo proveedor. WorkOS aparece, de hecho, entre los socios de infraestructura de identidad y gateway mencionados en el propio anuncio de socios de Cross App Access que hizo Okta en junio, y el mismo código funciona igual con un cliente que use Ping o Keycloak, porque la relación de confianza es una configuración de emisor por cliente dentro del propio producto, no una elección de proveedor.

La conclusión práctica que plantea el artículo no es qué proveedor de identidad elegir, sino si el propio servidor de autorización habla ya este patrón. Con tres plataformas de identidad implementando las mismas dos especificaciones en el espacio de ocho días, los compradores empresariales ya tienen un nombre para lo que van a pedir y una consola concreta desde la que pedirlo. La pregunta que debería resolver cualquier equipo que opere una aplicación B2B o un servidor MCP este trimestre es si un administrador empresarial podrá, el trimestre que viene, apuntar un agente hacia su producto y que funcione sin una pantalla de consentimiento por usuario ni una clave de API de larga duración.

El primer paso, según el artículo, es tan simple como publicar cuatro líneas de metadatos conforme a RFC 8414, porque un cliente lee el campo grant_types_supported para decidir si ofrece o no el flujo empresarial: un documento con issuer, token_endpoint y, entre los grant_types_supported, además de authorization_code y refresh_token, el tipo urn:ietf:params:oauth:grant-type:jwt-bearer. A partir de ahí, lo que queda es resolver client_id que la propia empresa no ha emitido y mantener, por cada cliente, una lista de emisores de confianza. Nada de esto es una apuesta por la plataforma de un proveedor concreto: es, más bien, el requisito previo para poder integrarse con cualquiera de ellos.