Skip to main content
La connexion d’agents IA et d’applications à d’autres ressources dans des environnements d’entreprise soulève deux problèmes majeurs : une visibilité limitée des TI sur le partage de données et des flux de consentement répétitifs pour les utilisateurs. L’accès interapplications (XAA) répond à ces défis en permettant aux administrateurs TI de définir de façon centralisée les contrôles d’accès régissant la connexion d’applications SaaS, comme les agents IA, 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 sécurité, une gouvernance et une expérience utilisateur améliorées pour l’organisation. XAA implémente l’Identity Assertion Authorization Grant, une extension OAuth en cours d’élaboration qui permet à une application demandeuse, telle qu’une application ou un agent IA, d’obtenir un jeton sécurisé auprès de l’IdP d’entreprise afin d’effectuer une requête à l’API d’une autre application (application de ressources) au nom de l’utilisateur final. Cela couvre à la fois les connexions application-à-application et agent-à-application. XAA est la solution protocolaire derrière l’extension autorisation gérée par l’entreprise de MCP, qui permet à un agent IA agissant comme client MCP de se connecter de façon transparente à un serveur MCP exposé par l’application de ressources. Pour en savoir plus, consultez Fonctionnement.

​
Principaux avantages

XAA offre des avantages clés pour chaque rôle au sein de votre écosystème d’entreprise :
  • Pour les administrateurs TI d’entreprise : contrôle centralisé, visibilité et application des politiques régissant 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 de l’IA d’entreprise pour favoriser la croissance de l’écosystème.
  • Pour les utilisateurs finaux : connexions simples et fluides entre les applications, éliminant les processus complexes de consentement OAuth.

​
Cas d’utilisation

Les cas d’utilisation courants de XAA comprennent :
  • Autorisation gérée par l’entreprise (agent-à-application) : un employé utilise un agent IA faisant office de client MCP pour consulter son application de calendrier et publier une mise à jour dans l’application de messagerie de l’entreprise. Au lieu d’obliger l’employé à passer par des flux de redirection et des invites de consentement, l’agent utilise XAA pour appeler de façon sécurisée les API des applications de calendrier et de messagerie, exposées comme serveurs MCP, si la politique d’accès de l’entreprise l’autorise.
  • Connecter des applications SaaS (application-à-application) : dans notre exemple précédent, les applications de calendrier et de messagerie de l’entreprise prennent toutes deux en charge XAA. Les employés peuvent facilement connecter l’application de messagerie à l’API de l’application de calendrier, sans redirection ni consentement de l’utilisateur, tout en respectant les politiques d’accès de l’entreprise.

​
Fonctionnement

Le flux XAA fait intervenir les acteurs suivants :
  • Application demandeuse : l’application ou l’agent IA qui doit accéder à une ressource.
  • Application de ressources : l’application qui possède la ressource protégée et l’expose par l’intermédiaire 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 demandeuse communique avec celui-ci pour demander, au nom de l’utilisateur, l’accès à l’application de ressources. Après avoir appliqué sa politique d’accès afin de vérifier si cette connexion interapplications est autorisée, l’IdP d’entreprise génère une assertion appelée ID-JAG. L’application demandeuse la présente ensuite à l’application de ressources pour obtenir un jeton d’accès permettant de consommer 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 demandeuse (Agent0) et à l’application de ressources (Todo0) :
  • Le serveur d’autorisation de l’application de ressources (Todo0) est fédéré avec l’IdP d’entreprise au moyen d’OIDC afin de pouvoir générer des jetons d’accès pour les utilisateurs finaux authentifiés par cet IdP.
  • L’application demandeuse (Agent0) est enregistrée auprès du serveur d’autorisation de l’application de ressources en tant que client OAuth 2.0 disposant d’un client_id et d’identifiants valides pour demander des jetons d’accès à ce serveur.
  • 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

Dans notre exemple Acme, le flux XAA de bout en bout comprend les étapes suivantes :
  1. L’employé d’Acme se connecte à l’application demandeuse (Agent0) à l’aide de l’authentification unique avec l’IdP d’entreprise. L’application demandeuse obtient un jeton d’ID afin de vérifier l’identité de l’employé d’Acme.
  2. L’application demandeuse envoie une requête d’échange de jetons à l’IdP afin d’échanger le jeton d’ID contre un Identity Assertion JWT Authorization Grant interdomaines, aussi appelé ID-JAG. L’IdP valide la requête et vérifie la politique XAA définie par l’administrateur TI d’Acme.
  3. Si la politique XAA le permet, l’IdP renvoie l’ID-JAG à l’application demandeuse.
  4. L’application demandeuse envoie une requête de jeton au serveur d’autorisation de l’application de ressources à l’aide de l’ID-JAG.
  5. Le serveur d’autorisation de l’application de ressources valide l’ID-JAG à l’aide de la clé publique qu’il utilise également pour son flux OpenID Connect avec l’IdP. S’il est valide, le serveur d’autorisation renvoie un jeton d’accès.
  6. L’application demandeuse envoie une requête à l’API de l’application de ressources avec le jeton d’accès.
L’application demandeuse et l’application de ressources peuvent chacune utiliser OIDC ou SAML pour se fédérer avec l’IdP d’entreprise lors de cette étape d’authentification unique. Consultez Tests de bout en bout pour comprendre le fonctionnement du flux XAA dans chaque cas.
Grâce au flux XAA, les politiques de l’administrateur TI d’Acme régissent l’accès d’Agent0 à Todo0, sans nécessiter de redirection ni d’interaction de la part de l’utilisateur final.

​
Démarrer

Auth0 prend en charge les deux volets du flux XAA. Selon le rôle que vous jouez dans l’écosystème, vous pouvez configurer votre Auth0 tenant en tant qu’application de ressources, application demandeuse, ou les deux.

​
Configurer Auth0 comme application de ressources

Configurez votre tenant Auth0 comme serveur d’autorisation de l’application de ressources afin que votre application SaaS puisse accepter les requêtes ID-JAG entrantes et émettre des jetons d’accès pour votre API. C’est la marche à suivre si vous êtes un fournisseur SaaS ou un propriétaire d’API qui souhaite que les agents IA et les applications d’entreprise consomment votre API en toute sécurité, sans exiger de consent flows de la part de l’end-user.

​
Configurer Auth0 comme application demandeuse

Configurez votre tenant Auth0 comme application demandeuse afin que votre agent IA ou votre application SaaS puisse appeler des API third-party pour le compte d’un utilisateur, sans passer par les consent flows OAuth. L’accès est régi par la policy de l’administrateur TI de l’entreprise dans son IdP. Auth0 stocke et réutilise les jetons que votre application récupère au moyen de XAA dans le Token Vault.

​
Limites de l’accès anticipé

L’accès anticipé de XAA présente les limites suivantes :
  • Il ne peut y avoir qu’une seule connexion activée pour XAA pour l’application de ressources par émetteur d’IdP d’entreprise. Par exemple, un même tenant Okta ne peut pas être utilisé pour plus d’une connexion d’entreprise d’application de ressources activée pour XAA.
  • La prise en charge du Token Vault avec les applications demandeuses XAA exige exactement une identité valide activée pour XAA liée au profil de l’utilisateur au moment de l’échange de jetons. Pour en savoir plus, consultez Accès interapplications avec Token Vault.
  • La prise en charge des organisations est limitée :
    • Une connexion est associée à une seule organisation. Plusieurs organisations ne peuvent pas être mappées à la même connexion pour l’accès à XAA.
    • Lorsque l’application demandeuse est configurée pour exiger l’utilisation des organisations, les utilisateurs doivent déjà être membres de l’organisation cible.
  • Aucune création dynamique d’utilisateurs : l’utilisateur doit s’être déjà connecté à votre application de ressources à l’aide de la connexion d’entreprise configurée. Sinon, la demande d’échange de l’assertion ID-JAG contre un jeton d’accès échouera avec l’erreur User not found.

​
Limites de débit

Dans le cadre de l’accès anticipé XAA, les échanges ID-JAG sur le point de terminaison /token de votre tenant Auth0 sont limités à 50 % au plus de la limite de débit globale de l’API d’authentification de votre tenant. Dans Private Cloud, les échanges de jetons de l’application demandeuse XAA utilisent les limites de débit du Token Vault propres à chaque forfait d’abonnement. Pour en savoir plus, notamment sur la limite exacte associée à votre forfait d’abonnement, consultez Configurations des limites de débit.