> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Créez et gérez des connexions agent-à-application et application-à-application, à l’aide de contrôles d’administration centralisés pour l’entreprise, avec prise en charge prête à l’emploi de l’autorisation gérée par l’entreprise de MCP.

# Accès interapplications (XAA)

export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
  const stageTextMap = {
    "beta": "bêta",
    "ea": "Accès anticipé"
  };
  const stageText = stageTextMap[stage] || "une phase de lancement du produit";
  const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
  const linkify = (text, url) => {
    return <a href={url} target="_blank" rel="noreferrer" class="link">{text}</a>;
  };
  const includeDetails = (plans, contact, terms) => {
    const hasDetails = terms || plans || contact;
    if (!hasDetails) return null;
    return <span data-as="p">
            {plans && <>Cette fonctionnalité est offerte avec les forfaits {linkify(`${plans}`, "https://auth0.com/pricing")}. </>}
            {contact && "Pour y participer, communiquez avec " + contact + ". "}
            {terms && <>En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit énoncées dans le {linkify("Master Subscription Agreement", "https://www.okta.com/legal")} d’Okta.</>}
        </span>;
  };
  return <Warning>
            <span data-as="p">
                <strong>La fonctionnalité {feature} est en {linkify(stageText, prsLink)}.</strong>
            </span>

            {includeDetails(plans, contact, terms)}
        </Warning>;
};

<ReleaseStageNotice feature="Cross App Access (XAA)" stage="ea" plans="Enterprise, B2B Pro, and B2B Essential" terms="true" />

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](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-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](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) de MCP, qui permet à un agent IA agissant comme [client MCP](https://modelcontextprotocol.io/) de se connecter de façon transparente à un serveur MCP exposé par l’application de ressources. Pour en savoir plus, consultez [Fonctionnement](#how-it-works).

<h2 id="key-benefits">
  Principaux avantages
</h2>

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.

<h2 id="use-cases">
  Cas d’utilisation
</h2>

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.

<h2 id="how-it-works">
  Fonctionnement
</h2>

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) :

<Frame>
  <img src="https://mintcdn.com/docs-dev-feat-init-gt-translations/75Dmca9T1euzHDps/docs/images/xaa/xaa_high_level_diagram.png?fit=max&auto=format&n=75Dmca9T1euzHDps&q=85&s=3147f0abf610f861de19fc337f64a6b0" alt="" width="1454" height="1034" data-path="docs/images/xaa/xaa_high_level_diagram.png" />
</Frame>

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

<h2 id="end-to-end-xaa-flow">
  Flux XAA de bout en bout
</h2>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/ai-agents-mcp/cross-app-access/end-to-end-testing) pour comprendre le fonctionnement du flux XAA dans chaque cas.
</Callout>

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.

<h2 id="get-started">
  Démarrer
</h2>

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.

<h3 id="set-up-auth0-as-resource-app">
  Configurer Auth0 comme application de ressources
</h3>

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.

| Lisez…                                                                                                      | Pour…                                                                                           |
| ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [Configurer Auth0 comme application de ressources](/docs/fr-ca/ai-agents-mcp/cross-app-access/resource-app) | Comprendre ce que cela implique et par où commencer.                                            |
| [Configuration de l'environnement](/docs/fr-ca/ai-agents-mcp/cross-app-access/set-up-xaa-test-environment)  | Configurer votre API et enregistrer une application demandeuse de test dans votre tenant Auth0. |
| [Okta comme IdP OIDC](/docs/fr-ca/ai-agents-mcp/cross-app-access/idp/okta-as-oidc-idp)                      | Configurer Okta comme IdP d’entreprise OIDC pour votre application de ressources.               |
| [Okta comme IdP SAML](/docs/fr-ca/ai-agents-mcp/cross-app-access/idp/okta-as-saml-idp)                      | Configurer Okta comme IdP d’entreprise SAML pour votre application de ressources.               |
| [Tests de bout en bout](/docs/fr-ca/ai-agents-mcp/cross-app-access/end-to-end-testing)                      | Tester le flux XAA complet une fois qu'Auth0 et l'IdP d’entreprise sont tous deux configurés.   |

<h3 id="set-up-auth0-as-requesting-app">
  Configurer Auth0 comme application demandeuse
</h3>

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](/docs/fr-ca/secure/tokens/token-vault).

| Lisez…                                                                                                                       | Pour…                                                                                                                                     |
| ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| [Configurer Auth0 comme application demandeuse](/docs/fr-ca/ai-agents-mcp/cross-app-access/requesting-app)                   | Comprendre ce que cela implique et par où commencer.                                                                                      |
| [Configuration de l’environnement](/docs/fr-ca/ai-agents-mcp/cross-app-access/requesting-app/set-up-xaa-test-environment)    | Configurer une application de ressources de test ainsi que la connection OIDC entre votre tenant et celui de l’application de ressources. |
| [Okta comme IdP OIDC](/docs/fr-ca/ai-agents-mcp/cross-app-access/requesting-app/idp/okta-as-oidc-idp)                        | Configurer Okta comme IdP d’entreprise OIDC pour votre application demandeuse.                                                            |
| [Accès interapplications avec le Token Vault](/docs/fr-ca/secure/call-apis-on-users-behalf/token-vault/xaa-with-token-vault) | Configurer le Token Vault pour stocker et réutiliser les jetons d’accès que votre application récupère au moyen de XAA.                   |

<h2 id="early-access-limitations">
  Limites de l’accès anticipé
</h2>

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](/docs/fr-ca/secure/call-apis-on-users-behalf/token-vault/xaa-with-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`.

<h2 id="rate-limits">
  Limites de débit
</h2>

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](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations).