Saltar al contenido principal
Esta guía parte de que usas Okta como tu Proveedor de identidad (IdP) empresarial y que tienes acceso administrativo a un inquilino de Okta que puedes usar para hacer pruebas. Si no tienes uno, consulta Crear y configurar tu inquilino de Okta.
Conectar aplicaciones de terceros y agentes de IA en una empresa genera dos problemas clave: poca visibilidad por parte de TI sobre el intercambio de datos y flujos de consentimiento repetitivos para los usuarios. Cross App Access (XAA) aborda estos desafíos al permitir que los administradores de TI definan de forma centralizada controles de acceso sobre cómo las aplicaciones SaaS, como los agentes de IA, se conectan en nombre de un usuario. Los administradores gestionan estas conexiones en un panel central, como la consola de administración de Okta, lo que elimina las interrupciones causadas por las pantallas de consentimiento de OAuth para los usuarios finales. El resultado es una mejora en la seguridad, la gobernanza y la experiencia de usuario de la organización. XAA implementa el Identity Assertion Authorization Grant, una extensión de OAuth en desarrollo que permite que un agente de IA o una aplicación (Requesting App) obtenga un token seguro a través del Proveedor de identidad (IdP) empresarial. Este token permite que la Requesting App llame a las API de otra aplicación (Resource App) en nombre del usuario final. Para obtener más información, consulta Cómo funciona.

​
Beneficios clave

XAA ofrece beneficios clave para cada rol de su ecosistema empresarial:
  • Para los administradores de TI empresarial: control centralizado, visibilidad y aplicación de políticas sobre el acceso de las aplicaciones a los datos empresariales y de usuario.
  • Para los proveedores de SaaS y los desarrolladores: integración estandarizada y segura para la IA empresarial que impulsa el crecimiento del ecosistema.
  • Para los usuarios finales: conexiones ágiles y sin fricción entre aplicaciones, lo que elimina los complejos flujos de consentimiento de OAuth.

​
Casos de uso

Los casos de uso más comunes de XAA incluyen:
  • Conectar agentes de IA con aplicaciones empresariales: un empleado usa un agente de IA para consultar su aplicación de calendario y publicar una actualización sobre su disponibilidad en la aplicación de mensajería empresarial. En lugar de exigir que el empleado pase por flujos de redirección y pantallas de consentimiento, el agente de IA usa XAA para obtener un token de acceso del IdP empresarial y llamar de forma segura a las API de la aplicación de calendario y de la aplicación de mensajería, si la política de acceso empresarial lo permite.
  • Conectar aplicaciones SaaS: en el ejemplo anterior, tanto el calendario empresarial como la aplicación de mensajería admiten XAA. Los empleados pueden conectar sin problemas la aplicación de mensajería para acceder a la API de la aplicación de calendario sin redirección del usuario ni consentimiento, mientras cumplen las políticas de acceso empresarial.

​
Cómo funciona

En el flujo XAA intervienen los siguientes actores:
  • Aplicación solicitante: la aplicación o el agente de IA que necesita acceder a un recurso.
  • Aplicación de recursos: la aplicación que posee el recurso protegido y lo expone mediante una API
  • IdP empresarial: el IdP, como Okta, que autentica a los empleados.
Después de que el usuario final se autentica con el IdP empresarial, la aplicación solicitante se comunica con el IdP empresarial para solicitar acceso a la aplicación de recursos en nombre del usuario. Tras aplicar su política de acceso para comprobar si esta conexión entre aplicaciones está permitida, el IdP empresarial genera una aserción denominada ID-JAG, que la aplicación solicitante presenta luego a la aplicación de recursos para obtener un token de acceso y consumir la API.  En el siguiente diagrama, Acme es el cliente empresarial cuyos empleados se autentican con su IdP empresarial, como Okta, para acceder a la aplicación solicitante (Agent0) y a la aplicación de recursos (Todo0):
  • El Servidor de autorización de la aplicación de recursos (Todo0) está federado con el IdP empresarial mediante OIDC para poder generar tokens de acceso para usuarios finales autenticados por ese IdP.
  • La aplicación solicitante (Agent0) está registrada en el Servidor de autorización de la aplicación de recursos como un cliente de OAuth 2.0 con un client_id válido y credenciales para solicitar tokens de acceso al Servidor de autorización de la aplicación de recursos.
  • El administrador de TI de Acme ha definido controles de acceso XAA entre Agent0 y Todo0.

​
Flujo XAA de extremo a extremo

Siguiendo con nuestro ejemplo de Acme, el flujo XAA de extremo a extremo consta de los siguientes pasos:
  1. El empleado de Acme inicia sesión en la aplicación solicitante (Agent0) mediante SSO con el IdP empresarial. La aplicación solicitante obtiene un token de ID para verificar la identidad del empleado de Acme.
  2. La aplicación solicitante realiza una solicitud de intercambio de tokens al IdP para intercambiar el token de ID por una concesión de autorización JWT de aserción de identidad entre dominios, también conocida como ID-JAG. El IdP valida la solicitud y comprueba la política XAA definida por el administrador de TI de Acme.
  3. Si la política XAA lo permite, el IdP devuelve el ID-JAG a la aplicación solicitante.
  4. La aplicación solicitante realiza una solicitud de token al Servidor de autorización de la aplicación de recursos (Todo0) mediante el ID-JAG.
  5. El Servidor de autorización de la aplicación de recursos valida el ID-JAG con la clave pública que también utiliza para su flujo de OpenID Connect con el IdP. Si es válido, el Servidor de autorización devuelve un token de acceso.
  6. La aplicación solicitante realiza una solicitud a la API de la aplicación de recursos con el token de acceso.
Al aprovechar el flujo XAA, las políticas del administrador de TI de Acme controlan el acceso de Agent0 a Todo0, sin requerir redirección ni interacción del usuario final.

​
Limitaciones de la beta

La beta de XAA tiene las siguientes limitaciones:
  • La aplicación solicitante debe ser un cliente confidencial y una aplicación propia en su inquilino de Auth0. No se admiten clientes públicos, como las SPA y las aplicaciones nativas.
  • La administración delegada no es compatible. El cliente empresarial no puede configurar directamente conexiones SSO en su inquilino de Auth0. La compatibilidad con SSO de autoservicio está prevista para una versión posterior.
  • Solo puede haber una conexión habilitada para XAA por cada emisor de IdP ascendente. El mismo inquilino de Okta no puede usarse para más de una conexión empresarial habilitada para XAA.
  • La compatibilidad con organizaciones es limitada:
    • Cada conexión tiene una asignación 1:1 con una Organización. Varias organizaciones no pueden asignarse a la misma conexión para el acceso a XAA.
    • Cuando la aplicación solicitante está configurada para requerir el uso de organizaciones, los usuarios ya deben ser miembros de la organización de destino.
  • Si no se especifica el parámetro resource en la solicitud de ID-JAG, la API de destino viene determinada por tenant.default_audience.
  • No hay creación dinámica de usuarios: el usuario debe haber iniciado sesión previamente en su aplicación de recursos mediante la conexión de Okta configurada. De lo contrario, la solicitud para intercambiar la aserción de ID-JAG por un token de acceso fallará con el error User not found error.

​
Límites de tasa

En la versión beta de XAA, los intercambios de ID-JAG en el endpoint /token de tu inquilino de Auth0 se limitarán a 5 RPS.