Passer au contenu principal
Cross App Access (XAA) est actuellement en version bêta. En utilisant cette fonctionnalité, vous acceptez les conditions applicables à l’essai gratuit prévues dans le Master Subscription Agreement d’Okta. Pour en savoir plus sur le cycle de publication des produits Auth0, consultez Étapes de publication des produits. Pour participer à ce programme, communiquez avec le support Auth0 ou votre gestionnaire de compte technique.
Ce guide suppose que vous utilisez Okta comme fournisseur d’identité d’entreprise (IdP) et que vous disposez d’un accès administrateur à un tenant Okta que vous pouvez utiliser pour vos tests. Si vous n’en avez pas, consultez Créez et configurez votre tenant Okta.
La connexion d’applications tierces et d’agents d’IA dans une entreprise crée deux problèmes majeurs : une visibilité limitée de l’équipe TI sur le partage de données et des processus de consentement répétitifs pour les utilisateurs. Cross App Access (XAA) répond à ces enjeux en permettant aux administrateurs TI de définir de façon centralisée les contrôles d’accès régissant la façon dont les applications SaaS, comme les agents d’IA, se connectent au nom d’un utilisateur. Les administrateurs gèrent ces connexions dans un tableau de bord central, comme la console d’administration Okta, ce qui élimine les invites de consentement OAuth perturbatrices pour les utilisateurs finaux. Il en résulte une amélioration de la sécurité, de la gouvernance et de l’expérience utilisateur au sein de l’organisation. XAA implémente le Identity Assertion Authorization Grant, une extension OAuth en cours d’élaboration qui permet à un agent d’IA ou à une application (Application requérante) d’obtenir un jeton sécurisé par l’entremise de l’IdP d’entreprise. Ce jeton permet à l’Application requérante d’appeler les API d’une autre application (Application de ressource) au nom de l’utilisateur final. Pour en savoir plus, consultez la section Fonctionnement.

​
Principaux avantages

XAA offre des avantages clés pour chaque rôle dans votre écosystème d’entreprise :
  • Pour les administrateurs TI d’entreprise : contrôle centralisé, visibilité et application des politiques concernant l’accès des applications aux données de l’entreprise et des utilisateurs.
  • Pour les fournisseurs SaaS et les développeurs : intégration normalisée et sécurisée pour l’IA d’entreprise afin de stimuler la croissance de l’écosystème.
  • Pour les utilisateurs finaux : connexions simplifiées et sans friction entre les applications, supprimant les flux de consentement OAuth complexes.

​
Cas d’utilisation

Les cas d’utilisation courants de XAA incluent :
  • Connecter des agents d’IA à des applications d’entreprise : Un employé utilise un agent d’IA pour lire les données de son application de calendrier et publier une mise à jour sur sa disponibilité dans l’application de messagerie d’entreprise. Plutôt que d’exiger que l’employé passe par des flux de redirection et des écrans de consentement, l’agent d’IA utilise XAA pour obtenir un jeton d’accès de l’IdP d’entreprise afin d’appeler en toute sécurité les API de l’application de calendrier et de l’application de messagerie, si cela est approuvé par la politique d’accès de l’entreprise.
  • Connecter des applications SaaS : Dans notre exemple précédent, l’application de calendrier d’entreprise et l’application de messagerie prennent toutes deux en charge XAA. Les employés peuvent connecter de manière transparente l’application de messagerie pour accéder à l’API de l’application de calendrier sans redirection de l’utilisateur ni consentement, tout en respectant les politiques d’accès de l’entreprise.

​
Fonctionnement

Le flux XAA met en jeu les acteurs suivants :
  • Application requérante : l’application ou l’agent IA qui doit accéder à une ressource.
  • Application de ressource : l’application qui possède la ressource protégée et l’expose au moyen d’une API.
  • IdP d’entreprise : l’IdP, comme Okta, qui authentifie les employés.
Une fois que l’utilisateur final s’est authentifié auprès de l’IdP d’entreprise, l’Application requérante contacte l’IdP d’entreprise pour demander l’accès à l’Application de ressource au nom de l’utilisateur. Après avoir appliqué sa politique d’accès pour vérifier si cette connexion entre applications est autorisée, l’IdP d’entreprise génère une assertion appelée ID-JAG, que l’Application requérante présente ensuite à l’Application de ressource pour obtenir un jeton d’accès afin d’utiliser l’API.  Dans le diagramme suivant, Acme est le client d’entreprise dont les employés s’authentifient auprès de leur IdP d’entreprise, comme Okta, pour accéder à l’Application requérante (Agent0) et à l’Application de ressource (Todo0) :
  • Le Serveur d’autorisation de l’Application de ressource (Todo0) est fédéré avec l’IdP d’entreprise via OIDC afin de pouvoir générer des jetons d’accès pour les utilisateurs finaux authentifiés par cet IdP.
  • L’Application requérante (Agent0) est enregistrée auprès du Serveur d’autorisation de l’Application de ressource comme un client OAuth 2.0 avec un client_id valide et des informations d’identification lui permettant de demander des jetons d’accès au Serveur d’autorisation de l’Application de ressource.
  • L’administrateur TI d’Acme a défini des contrôles d’accès XAA entre Agent0 et Todo0.

​
Flux XAA de bout en bout

En gardant l’exemple d’Acme en tête, le flux XAA de bout en bout comporte les étapes suivantes :
  1. L’employé d’Acme se connecte à l’application requérante (Agent0) au moyen du SSO avec l’IdP d’entreprise. L’application requérante obtient un jeton ID pour vérifier l’identité de l’employé d’Acme.
  2. L’application requérante envoie une demande d’échange de jeton à l’IdP pour échanger le jeton ID contre une autorisation JWT d’assertion d’identité inter-domaines (Identity Assertion JWT Authorization Grant), aussi appelée ID-JAG. L’IdP valide la demande et vérifie la stratégie XAA définie par l’administrateur TI d’Acme.
  3. Si la stratégie XAA le permet, l’IdP renvoie l’ID-JAG à l’application requérante.
  4. L’application requérante envoie une demande de jeton à l’aide de l’ID-JAG au serveur d’autorisation de l’application de ressources (Todo0).
  5. Le serveur d’autorisation de l’application de ressources valide l’ID-JAG en utilisant la clé publique qu’il utilise également pour son flux OpenID Connect avec l’IdP. Si la validation réussit, le serveur d’autorisation renvoie un jeton d’accès.
  6. L’application requérante envoie une requête avec le jeton d’accès à l’API de l’application de ressources.
En tirant parti du flux XAA, les stratégies de l’administrateur TI d’Acme régissent l’accès d’Agent0 à Todo0, sans exiger de redirection ni d’interaction de la part de l’utilisateur final.

​
Limitations de la version bêta

XAA Beta présente les limitations suivantes :
  • L’application requérante doit être un client confidentiel et une application propriétaire (first-party app) dans votre tenant Auth0. Les clients publics, comme les SPA et les applications natives, ne sont pas pris en charge.
  • L’administration déléguée n’est pas prise en charge. Le client d’entreprise ne peut pas configurer directement les connexions SSO sur votre tenant Auth0. La prise en charge de Self-Service SSO est prévue pour une version ultérieure.
  • Il ne peut y avoir qu’une seule connexion avec XAA activé par émetteur IdP en amont. Le même tenant Okta ne peut pas être utilisé pour plus d’une connexion d’entreprise avec XAA activé.
  • La prise en charge des organisations est limitée :
    • Une connexion a une affectation 1:1 avec une organisation. Plusieurs organisations ne peuvent pas être associées à la même connexion pour l’accès XAA.
    • Lorsque l’application requérante est configurée pour exiger l’utilisation des organisations, les utilisateurs doivent déjà être membres de l’organisation cible.
  • Si le paramètre resource n’est pas spécifié dans la requête ID-JAG, l’API cible est déterminée par tenant.default_audience.
  • Aucune création dynamique d’utilisateur : l’utilisateur doit s’être déjà connecté à votre application de ressource à l’aide de la connexion Okta configurée. Sinon, la requête d’échange de l’assertion ID-JAG contre un jeton d’accès échouera avec une User not found error.

​
Limites de débit

Dans XAA Beta, les échanges ID-JAG sur le point de terminaison /token de votre tenant Auth0 seront soumis à une limite de 5 requêtes par seconde (RPS).