Passer au contenu principal
La rotation des jetons d’actualisation est une technique d’obtention de nouveaux jetons d’accès à l’aide de jetons d’actualisation qui va au-delà de l’authentification silencieuse. Les jetons d’actualisation ont typiquement une durée de vie plus longue et peuvent être utilisés pour demander des jetons d’accès après que les jetons d’accès de courte durée de vie aient expiré. Les jetons d’actualisation sont souvent utilisés dans les applications natives d’appareils mobiles, en parallèle avec les jetons d’accès de courte durée, pour fournir un accès UX sans heurt sans devoir émettre de jetons d’accès, lesquels durent plus longtemps. Avec la rotation des jetons d’actualisation dans le Auth0 Dashaboard (Tableau de bord Auth0), chaque fois que votre application échange un jeton d’actualisation pour obtenir un nouveau jeton d’accès, un nouveau jeton d’actualisation est renvoyé. Par conséquent, vous n’avez plus de jeton d’actualisation de durée de vie plus longue, lequel pourrait offrir un accès illégitime aux ressources. Puisque les jetons d’actualisation sont constamment échangés et invalidés, le risque est diminué. Le fonctionnement de la rotation des jetons d’actualisation dans Auth0 est conforme au PCA OAuth 2.0 et fonctionne avec les flux suivants :

​
Maintenir les sessions utilisateurs dans les SPA

Jusqu’à très récemment, les SPA (applications à page unique) maintenaient la session utilisateur en utilisant un Flux Code d’autorisation avec PKCE conjointement à une authentification silencieuse. Les récents développements en technologie de navigateurs privés comme la Prévention du suivi intelligent (Intelligent Tracking Prevention, ITP) préviennent l’accès au témoin de session Auth0, demandant alors à l’utilisateur de s’authentifier.
Jeton d’actualisation Rotation Maintenir les sessions d’utilisateurs dans les diagrammes de SPA
Malheureusement, les jetons d’actualisation d’une longue durée de vie ne sont pas appropriés avec la Prévention du suivi intelligent (ITP) puisqu’il n’y a pas de mécanisme de stockage dans le navigateur qui puisse assurer un accès uniquement par l’application. Parce qu’il existe des vulnérabilités qui peuvent être exploitées pour obtenir ces artefacts de grande valeur et octroyer un passage à des acteurs malicieux vers des ressources protégées, l’utilisation des jetons d’actualisation avec les SPA est fortement découragée. La rotation des jetons d’actualisation offre une façon de remédier aux sessions d’utilisateurs finaux perdues en raison des effets secondaires des mécanismes de navigateurs privés. Parce que la rotation de jeton d’actualisation ne repose pas sur l’accès au témoin de session Auth0, il n’est pas affecté par l’ITP ou des mécanismes similaires. Le schéma suivant illustre comment la rotation des jetons d’actualisation est utilisée conjointement avec le Flux Code d’autorisation avec PKCE, mais le principe général d’obtention d’un nouveau jeton d’actualisation avec chaque échange s’applique à tous les flux pris en charge.
Jeton d’actualisation Rotation Maintenir les sessions d’utilisateurs dans les diagrammes de SPA Diagramme d’état
Cela signifie que vous pouvez utiliser les jetons d’actualisation en toute sécurité pour mitiger les effets négatifs des outils des navigateurs privés et fournir un accès continu aux utilisateurs finaux, cela sans inconvénient au service.

​
Détection automatique de réutilisation

Lorsqu’un client a besoin d’un nouveau jeton d’accès, il envoie le jeton d’actualisation avec une requête à Auth0 pour obtenir une paire de jetons. Dès que la nouvelle paire est émise à Auth0, le jeton d’actualisation utilisé dans la requête est invalidé. Cela protège votre application contre les attaques par réinsertion résultant de jetons compromis. S’il ne peut pas appliquer la contrainte à l’envoyeur, il est impossible pour le serveur d’autorisations de savoir quel acteur est légitime ou malicieux dans un cas d’attaque par réinsertion. Il est donc important que le jeton d’actualisation le plus récemment émis soit immédiatement invalidé lorsqu’un jeton d’actualisation utilisé précédemment (déjà invalidé) est envoyé au serveur d’authentification. Cela empêche tout jeton d’actualisation de la même famille de jetons (tous les jetons d’actualisation provenant du jeton d’actualisation original émis) d’être utilisé pour obtenir de nouveaux jetons d’accès. Par exemple, considérez les scénarios suivants :
Jeton d’actualisation Rotation Réutilisation Détection Diagramme d’état
  1. Le client légitime possède le jeton d’actualisation 1, qui est divulgué ou volé par le client malveillant.
  2. Le client légitime utilise le jeton d’actualisation 1 pour obtenir une nouvelle paire de 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 alors 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 revoit une réponse de refus d’accès au client malicieux.
  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 revoit une réponse de refus d’accès au client légitime.
  7. Une réauthentification est nécessaire.
Ce mécanisme de protection fonctionne indépendamment du fait que le client légitime ou le client malveillant soit en mesure d’é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 réauthentifie. Lorsque la réutilisation est détectée, Auth0 enregistre les événements de réutilisation détectés (tels que ferrt indiquant l’échec de l’échange) dans les journaux. Cela peut être particulièrement utile en conjonction avec les capacités d’exportation de journaux d’Auth0 pour détecter 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 acquérir un jeton d’accès avant que le client légitime ne tente 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 autre jeton d’actualisation émis ultérieurement) est automatiquement révoqué lorsque le client légitime tente d’utiliser le jeton d’actualisation 1, comme le montre le diagramme suivant :
Jeton d’actualisation Rotation Réutilisation Détection Diagramme d’état

​
Assistance trousse SDK

Les trousses SDK suivantes incluent la prise en charge de la rotation des jetons d’actualisation et la détection de réutilisation automatique.
  • Trousse SDK Auth0 pour les applications à page unique (SPA)
  • Flutter (Web)
  • Trousse SDK Swift (iOS)
  • Trousse SDK pour Android
  • Flutter
  • Trousse SDK native React
  • WPF/Winforms
  • Xamarin
Pour obtenir la documentation spécifique à ces trousses SDK, consultez la page Bibliothèques de trousses SDK Auth0. Vous pouvez choisir de stocker vos jetons de manière locale ou dans la mémoire d’un navigateur. L’option par défaut est de les stocker dans la mémoire du navigateur. Voir Bonnes pratiques en matière de jetons pour des recommandations sur le stockage des jetons. Vous devez permettre l’accès hors ligne et demander la permission d’accès hors ligne dans la trousse SDK client.

​
En savoir plus

⌘I