Rotation des jetons d’actualisation

Décrit comment la rotation des jetons d’actualisation renforce la sécurité en émettant un nouveau jeton d’actualisation chaque fois qu’un client utilisant des jetons d’actualisation envoie à Auth0 une demande de nouveau jeton d’accès.

La rotation des jetons d’actualisation est une technique qui permet d’obtenir de nouveaux jetons d’accès à l’aide de jetons d’actualisation et qui va au-delà de l’authentification silencieuse. 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 que les jetons d’accès à courte durée de vie ont expiré. Les jetons d’actualisation sont souvent utilisés dans les applications natives sur appareils mobiles avec des jetons d’accès à courte durée de vie afin d’offrir une expérience utilisateur fluide, sans devoir émettre de jetons d’accès à longue durée de vie.

Lorsque la rotation des jetons d’actualisation est activée dans le tableau de bord Auth0, chaque fois qu’une application échange un jeton d’actualisation pour obtenir un nouveau jeton d’accès, un nouveau jeton d’actualisation est également renvoyé. Ainsi, vous n’avez plus de jeton d’actualisation à longue durée de vie qui, s’il était compromis, pourrait donner un accès illégitime aux ressources. Comme les jetons d’actualisation sont continuellement échangés et invalidés, le risque diminue.

Le fonctionnement de la rotation des jetons d’actualisation dans Auth0 est conforme au OAuth 2.0 BCP et est compatible avec les flux suivants :

• Flux du code d’autorisation
• Flux du code d’autorisation avec Proof Key for Code Exchange
• Flux d’autorisation d’appareil
• Flux du mot de passe du propriétaire de la ressource

​

Maintenir les sessions utilisateur dans les SPA

Jusqu’à tout récemment, les SPA maintenaient la session utilisateur au moyen du flux Authorization Code avec PKCE, en combinaison avec l’authentification silencieuse. Or, les avancées récentes en matière de protection de la vie privée dans les navigateurs, comme Intelligent Tracking Prevention (ITP), empêchent l’accès au cookie de session Auth0, ce qui oblige les utilisateurs à s’authentifier de nouveau.

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 capable de garantir un accès exclusivement à l’application visée. Comme 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 au problème de perte des sessions des utilisateurs finaux causée par les effets secondaires des mécanismes de protection de la vie privée des navigateurs. Comme elle ne dépend pas de l’accès au cookie de session Auth0, elle n’est pas affectée par ITP ni par des mécanismes semblables.

Le diagramme d’état suivant montre comment la rotation des jetons d’actualisation est utilisée conjointement avec le flux Authorization Code avec PKCE, mais le principe général consistant à obtenir un nouveau jeton d’actualisation à chaque échange s’applique à tous les flux pris en charge.

Cela signifie que vous pouvez utiliser les jetons d’actualisation en toute sécurité pour atténuer les effets indésirables des outils de protection de la vie privée 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 dans 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 résultant de jetons compromis.

Sans contrainte d’émetteur, il est impossible pour le serveur d’autorisation de savoir 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 immédiatement invalidé 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 (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, prenons le scénario suivant :

1. Le client légitime possède le jeton d’actualisation 1, et celui-ci 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 détecte que le jeton d’actualisation 1 est réutilisé et invalide immédiatement toute 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 nouvelle authentification est requise.

Ce mécanisme de protection fonctionne, que ce soit le client légitime ou le client malveillant qui parvienne à é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 sont refusées jusqu’à ce que l’utilisateur s’authentifie de nouveau. 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 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 obtenir 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 jeton d’actualisation émis par la suite) est automatiquement révoqué lorsque le client légitime essaie d’utiliser le jeton d’actualisation 1, comme l’illustre le diagramme suivant :

​

Prise en charge des SDK

Les SDK suivants prennent en charge la rotation des jetons d’actualisation et la détection automatique de leur réutilisation.

• SDK SPA Auth0
• Flutter (Web)
• SDK Swift (iOS)
• SDK Android
• Flutter
• SDK React Native
• WPF / Winforms
• Xamarin

Pour obtenir la documentation spécifique à ces SDK, consultez la page Bibliothèques SDK Auth0.

Vous pouvez choisir de stocker les jetons soit dans le stockage local, soit 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 des recommandations sur le stockage des jetons. Vous devez activer l’accès hors ligne et demander la portée d’accès hors ligne dans le SDK client.

​

Pour en savoir plus

• Configurer la rotation des jetons d’actualisation
• Désactiver la rotation des jetons d’actualisation
• Configurer l’expiration des jetons d’actualisation
• Bonnes pratiques relatives aux jetons