> ## 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écrit comment la rotation des jetons d’actualisation améliore la sécurité en émettant un nouveau jeton d’actualisation chaque fois qu’un client utilisant des jetons d’actualisation envoie une requête à Auth0 pour obtenir un nouvel jeton d’accès. # Rotation des jetons d’actualisation La rotation des jetons d’actualisation est une technique qui permet d’obtenir de nouveaux jetons d’accès au moyen de jetons d’actualisation, au-delà de la [silent authentication](/docs/fr-ca/authenticate/login/configure-silent-authentication). Les jetons d’actualisation ont généralement une durée de vie plus longue et peuvent servir à demander de nouveaux jetons d’accès une fois les jetons d’accès à plus courte durée de vie expirés. Les jetons d’actualisation sont souvent utilisés dans les applications natives sur les appareils mobiles, avec des jetons d’accès à courte durée de vie, afin d’offrir une expérience utilisateur fluide sans avoir à émettre de jetons d’accès à longue durée de vie. Lorsque la rotation des jetons d’actualisation est activée dans le Auth0 Dashboard, chaque fois qu’une application échange un jeton d’actualisation pour obtenir un nouvel jeton d’accès, un nouveau jeton d’actualisation est également renvoyé. Vous n’avez donc plus de jeton d’actualisation à longue durée de vie qui, s’il était compromis, pourrait fournir un accès illégitime à des ressources. Comme les jetons d’actualisation sont continuellement échangés et invalidés, le risque est réduit. Le fonctionnement de la rotation des jetons d’actualisation dans Auth0 est conforme au [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) et s’applique aux flows suivants : * [flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) * [flux de code d’autorisation with Proof Key for Code Exchange](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) * [Device Authorization Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/device-authorization-flow) * [Resource Owner Password Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
## Maintenir les sessions utilisateur dans les SPA
Jusqu’à tout récemment, les SPA maintenaient la session de l’utilisateur au moyen du flux de code d’autorisation avec PKCE, conjointement avec l’authentification silencieuse. Les récentes avancées en matière de protection de la vie privée dans les navigateurs, comme Intelligent Tracking Prevention (ITP), empêchent toutefois l’accès au témoin de session Auth0, ce qui oblige les utilisateurs à se réauthentifier. Diagramme de la rotation des jetons d’actualisation pour maintenir les sessions utilisateur dans les SPA Malheureusement, les jetons d’actualisation à longue durée de vie ne conviennent pas aux SPA, car il n’existe dans un navigateur aucun mécanisme de stockage persistant qui puisse garantir que seule l’application visée y aura accès. Puisque certaines vulnérabilités peuvent être exploitées pour obtenir ces artefacts de grande valeur et permettre à des acteurs malveillants d’accéder à des ressources protégées, l’utilisation de jetons d’actualisation dans les SPA a été fortement déconseillée. La rotation des jetons d’actualisation offre une solution pour éviter la perte des sessions des utilisateurs finaux causée par les effets secondaires des mécanismes de confidentialité des navigateurs. Comme la rotation des jetons d’actualisation ne dépend pas de l’accès au témoin de session Auth0, elle n’est pas touchée par ITP ni par des mécanismes semblables. Le diagramme d’état suivant illustre comment la rotation des jetons d’actualisation est utilisée conjointement avec le flux de code d’autorisation avec PKCE, mais le principe général qui consiste à obtenir un nouveau jeton d’actualisation à chaque échange s’applique à tous les flux pris en charge. Diagramme d’état de la rotation des jetons d’actualisation pour maintenir les sessions utilisateur dans les SPA Cela signifie que vous pouvez utiliser en toute sécurité des jetons d’actualisation pour atténuer les effets négatifs des outils de confidentialité des navigateurs et offrir aux utilisateurs finaux un accès continu, sans nuire à l’expérience utilisateur.
## Détection automatique de la réutilisation
Lorsqu’un client a besoin d’un nouveau jeton d’accès, il envoie le jeton d’actualisation avec la requête à Auth0 pour obtenir une nouvelle paire de jetons. Dès que cette nouvelle paire est émise par Auth0, le jeton d’actualisation utilisé dans la requête est invalidé. Cela protège votre application contre les attaques par rejeu causées par des jetons compromis. Sans appliquer de contrainte de l’émetteur, il est impossible pour le serveur d’autorisation de déterminer quel acteur est légitime ou malveillant en cas d’attaque par rejeu. Il est donc important que le jeton d’actualisation émis le plus récemment soit lui aussi invalidé immédiatement lorsqu’un jeton d’actualisation déjà utilisé (et déjà invalidé) est envoyé au serveur d’autorisation. Cela empêche l’utilisation de tout jeton d’actualisation de la même famille de jetons (c’est-à-dire tous les jetons d’actualisation dérivés du jeton d’actualisation initial émis pour le client) pour obtenir de nouveaux jetons d’accès. Par exemple, considérez le scénario suivant : Diagramme d’état de détection de la réutilisation de la rotation des jetons d’actualisation 1. Le client légitime possède le **jeton d’actualisation 1**, qui est divulgué au client malveillant ou volé par celui-ci. 2. Le client légitime utilise le **jeton d’actualisation 1** pour obtenir une nouvelle paire jeton d’actualisation/jeton d’accès. 3. Auth0 renvoie le **jeton d’actualisation 2/jeton d’accès 2**. 4. Le client malveillant tente ensuite d’utiliser le **jeton d’actualisation 1** pour obtenir un jeton d’accès. Auth0 reconnaît que le jeton d’actualisation 1 est réutilisé et invalide immédiatement la famille de jetons d’actualisation, y compris le **jeton d’actualisation 2**. 5. Auth0 renvoie une réponse d’accès refusé au client malveillant. 6. Le **jeton d’accès 2** expire et le client légitime tente d’utiliser le **jeton d’actualisation 2** pour demander une nouvelle paire de jetons. Auth0 renvoie une réponse d’accès refusé au client légitime. 7. Une réauthentification est nécessaire. Ce mécanisme de protection fonctionne, que le client légitime ou le client malveillant réussisse à échanger le **jeton d’actualisation 1** contre une nouvelle paire de jetons avant l’autre. Dès qu’une réutilisation est détectée, toutes les requêtes suivantes seront refusées jusqu’à ce que l’utilisateur se réauthentifie. Lorsqu’une réutilisation est détectée, Auth0 consigne dans les journaux les [événements](/docs/fr-ca/deploy-monitor/logs/log-event-type-codes) de réutilisation détectée (comme `ferrt`, qui indique un échange échoué). Cela peut être particulièrement utile avec les capacités de [diffusion des journaux](/docs/fr-ca/customize/log-streams) d’Auth0 pour repérer les activités suspectes. Un autre exemple est celui où le client malveillant vole le **jeton d’actualisation 1** et l’utilise avec succès pour obtenir un jeton d’accès avant que le client légitime n’essaie d’utiliser le **jeton d’actualisation 1**. Dans ce cas, l’accès du client malveillant serait de courte durée, car le **jeton d’actualisation 2** (ou tout jeton d’actualisation émis par la suite) est automatiquement révoqué lorsque le client légitime tente d’utiliser le **jeton d’actualisation 1**, comme le montre le diagramme suivant : Diagramme d’état de détection de la réutilisation de la rotation des jetons d’actualisation
## Prise en charge des SDK
Les SDK suivants prennent en charge la rotation des jetons d’actualisation et la détection automatique de la réutilisation. * Auth0 SPA SDK * Flutter (Web) * SDK Swift (iOS) * Android SDK * Flutter * SDK React Native * WPF / Winforms * Xamarin Pour consulter la documentation propre à ces SDK, visitez la page [Bibliothèques SDK Auth0](/docs/fr-ca/libraries). Vous pouvez choisir de stocker les jetons dans le stockage local ou dans la mémoire du navigateur. Par défaut, ils sont stockés dans la mémoire du navigateur. Consultez [Bonnes pratiques relatives aux jetons](/docs/fr-ca/secure/tokens/token-best-practices) pour obtenir des recommandations sur le stockage des jetons. Vous devez activer l’accès hors ligne et demander la portée `offline_access` dans le SDK client.
## En savoir plus
* [Configurer la rotation des jetons d’actualisation](/docs/fr-ca/secure/tokens/refresh-tokens/configure-refresh-token-rotation) * [Désactiver la rotation des jetons d’actualisation](/docs/fr-ca/secure/tokens/refresh-tokens/disable-refresh-token-rotation) * [Configurer l’expiration des jetons d’actualisation](/docs/fr-ca/secure/tokens/refresh-tokens/configure-refresh-token-expiration) * [Pratiques exemplaires relatives aux jetons](/docs/fr-ca/secure/tokens/token-best-practices)