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

> Découvrez les jetons d’actualisation multiresources Auth0 qui permettent à un seul jeton d’actualisation d’accéder à plusieurs API.

# Jeton d’actualisation multiresource

Les <Tooltip tip="Refresh Token : Jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Refresh+Tokens">jetons d’actualisation</Tooltip> multiresources (MRRT) permettent d’utiliser un seul [jeton d’actualisation](/docs/fr-ca/secure/tokens/refresh-tokens) pour obtenir des [jetons d’accès](/docs/fr-ca/secure/tokens/access-tokens) pour plusieurs [API](/docs/fr-ca/get-started/apis), chacune avec ses propres portées et permissions. Le MRRT repose sur le comportement standard d’[OAuth 2.0](/docs/fr-ca/authenticate/protocols/oauth) en permettant aux jetons d’actualisation de conserver plusieurs politiques d’autorisation.

Lorsqu’une application échange un jeton d’actualisation contre un <Tooltip tip="Access Token : Informations d’identification d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisées pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip>, elle peut choisir parmi un ensemble d’<Tooltip tip="Audience : Identifiant unique de l’audience d’un jeton émis. Nommée aud dans un jeton, sa valeur contient l’ID d’une application (Client ID) pour un ID Token ou d’une API (API Identifier) pour un Access Token." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=audience">audiences</Tooltip> et de portées configurées. Ainsi, le MRRT simplifie les flux d’authentification en évitant d’avoir à obtenir un nouveau jeton d’actualisation pour chaque API.
Lors de l’utilisation du MRRT, Auth0 combine deux sources d’autorisation pour déterminer quel jeton d’accès émettre pendant un échange de jeton d’actualisation :

1. L’audience et les portées accordées dans le flux d’authentification initial.
2. L’audience et les portées configurées dans la politique MRRT de l’application.

Les applications peuvent ainsi réutiliser le jeton d’actualisation non seulement pour les API demandées à la connexion, mais aussi pour d’autres API autorisées par la politique MRRT.

**Les principaux avantages du MRRT sont les suivants** :

* Un seul jeton d’actualisation par application à gérer pour contrôler l’accès à plusieurs API.
* Plus besoin de passer par un <Tooltip tip="Authorization Flow : Grant d’autorisation (ou workflow) spécifié dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+flow">flux d’autorisation</Tooltip> complet chaque fois que votre application doit accéder à une nouvelle API.
* De meilleures performances et une charge réduite sur le <Tooltip tip="Authorization Server : Serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip>.
* Réduction du risque de [limitation du taux de requêtes](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy) en raison de flux complets de code d’autorisation répétés.

<div id="how-it-works">
  ## Fonctionnement
</div>

<Frame>
  <img src="https://mintcdn.com/translations/eVsQcTnbClN-oB7d/docs/images/cdy7uua7fh8z/1V12Rzfm8mafMTaxlcEr25/a9ab2a335a835f0c2ae61eb1d767c9fa/Docs_Diagram_Toolkit_-_Carlos__1_.png?fit=max&auto=format&n=eVsQcTnbClN-oB7d&q=85&s=b8d95753dc3b63ab0d807f9ee96b2547" alt="" width="1400" height="943" data-path="docs/images/cdy7uua7fh8z/1V12Rzfm8mafMTaxlcEr25/a9ab2a335a835f0c2ae61eb1d767c9fa/Docs_Diagram_Toolkit_-_Carlos__1_.png" />
</Frame>

1. L’application s’authentifie auprès d’Auth0.

2. Auth0 renvoie un jeton d’accès et un jeton d’actualisation multiresource.

3. L’application utilise le jeton d’accès pour appeler l’API 1.

4. L’application échange le jeton d’actualisation multiresource afin d’accéder à l’API 2.

5. Auth0 renvoie un nouveau jeton d’accès pour l’API 2.

6. L’application appelle l’API 2 à l’aide du nouveau jeton d’accès.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Par exemple, une application native authentifie l’utilisateur et demande l’accès à l’audience `https://api.example.com`. Ensuite, l’application doit accéder à l’audience `https://billing.example.com`. Si les deux API sont incluses dans la politique MRRT de l’application, celle-ci peut échanger un jeton d’actualisation contre un jeton d’accès pour l’une ou l’autre des API.
</Callout>

Découvrez comment [Configurer et Implement le jeton d’actualisation multiresource](/docs/fr-ca/secure/tokens/refresh-tokens/multi-resource-refresh-token/configure-and-implement-multi-resource-refresh-token).

<div id="limitations">
  ## Limitations
</div>

* Chaque jeton d’accès émis au moyen de MRRT est limité à une seule API. Si votre application doit accéder à plusieurs API, vous devez demander des jetons d’accès distincts pour chacune d’elles.
* MRRT prend uniquement en charge les [applications de première partie](/docs/fr-ca/get-started/applications/first-party-and-third-party-applications#first-party-applications).
* MRRT prend en charge les API configurées pour [permettre d’ignorer le consentement de l’utilisateur](/docs/fr-ca/get-started/applications/third-party-applications/user-consent-and-third-party-applications#skip-consent-for-first-party-applications).
* La <Tooltip tip="Management API : un produit qui permet aux clients d'effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip> d’Auth0 ne peut pas être incluse dans les politiques MRRT.