Skip to main content
L’accès interapplications (XAA) pour l’application de ressources est en accès anticipé. Les clients Enterprise, B2B Pro et B2B Essential peuvent l’utiliser comme fonctionnalité d’Enterprise Connections. Vous pouvez également l’essayer pendant la période d’essai sur les tenants Free. En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit figurant dans le contrat-cadre d’abonnement d’Okta.
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.
Le serveur d’autorisation Auth0 de l’application de ressources et l’IdP d’entreprise doivent tous deux être configurés pour que XAA fonctionne. Commencez par Configuration de l’environnement pour configurer la partie Auth0, puis consultez le guide approprié dans Intégration d’IdP — Okta comme IdP OIDC et Okta comme IdP SAML — selon l’IdP et le protocole que vous souhaitez utiliser pour établir la fédération avec celui-ci.

​
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.

​
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 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 activée pour XAA.
  • 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 ressource à 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 error.

​
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. Pour en savoir plus, notamment sur la limite exacte associée à votre forfait d’abonnement, consultez Configurations des limites de débit.