Skip to main content
La est une technique qui permet d’obtenir de nouveaux au moyen de jetons d’actualisation, au-delà de la 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 est activée dans le , 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 et s’applique aux flows suivants :

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