Stockage des jetons

Découvrez comment et où stocker les jetons utilisés dans le cadre d’une authentification par jetons.

Aperçu

Concepts clés

• La façon dont vous choisissez de stocker votre jeton est essentielle pour protéger votre application contre les attaques malveillantes.
• Passez en revue les scénarios pour chaque type d’application.
• Déterminez quelle méthode convient le mieux à votre technologie.

La sécurisation des SPA qui effectuent des appels d’API s’accompagne de son propre lot d’enjeux. Vous devrez vous assurer que les jetons et les autres données sensibles ne sont pas vulnérables au script intersite (XSS) et qu’ils ne peuvent pas être lus par un JavaScript malveillant.

Pour en savoir plus, consultez le JWT Handbook et The Ultimate Guide to Next.js Authentication with Auth0.

​

Scénarios de site statique Next.js

Lorsque vous créez une application Next.js, l’authentification peut être nécessaire dans les cas suivants :

1. Lors de l’accès à une page
2. Lors de l’accès à une route d’API
3. Lorsque votre application effectue un appel d’API à une API hébergée à l’extérieur de votre application Next.js au nom de l’utilisateur

Lorsqu’un serveur est disponible, votre application peut gérer l’interaction avec Auth0 et créer une session, mais dans ce modèle, nous n’avons pas de backend. Tout se passe dans le frontend :

1. L’utilisateur est redirigé vers Auth0.

2. Une fois l’utilisateur connecté avec succès, il est redirigé vers l’application.

3. Le côté client effectuera l’échange de code avec Auth0 et récupérera les id_token et access_token de l’utilisateur, qui seront stockés en mémoire.

   

Application web traditionnelle

Si votre application utilise un scénario de connexion qui ne nécessite pas d’appels d’API, seul un ID token est requis. Il n’est pas nécessaire de le stocker. Vous pouvez le valider et en extraire les données dont vous avez besoin.

Si votre application doit appeler des API au nom de l’utilisateur, des jetons d’accès et, éventuellement, des jetons d’actualisation sont nécessaires. Ils peuvent être stockés côté serveur ou dans un cookie de session. Le cookie doit être chiffré et avoir une taille maximale de 4 KB. Si les données à stocker sont volumineuses, stocker les jetons dans le cookie de session n’est pas une option viable.

Utilisez les types de flow suivants dans ces scénarios :

• Authorization Code Flow
• Quickstarts pour les applications web régulières

Application native/mobile

Stockez les jetons dans un espace de stockage sécurisé offert par le système d’exploitation et limitez l’accès à cet espace. Par exemple, utilisez KeyStore pour Android et Keychain pour iOS.

Utilisez les types de flow suivants dans ces scénarios :

• Authorization Code Flow with Proof Key for Code Exchange
• Enregistrer et renouveler les jetons pour Swift
• Quickstarts pour les applications native/mobile

Application monopage

Nous vous recommandons d’utiliser le Auth0 SPA SDK pour gérer le stockage des jetons, la gestion des sessions et les autres détails à votre place.

Lorsque la SPA appelle uniquement une API fournie à partir d’un domaine qui peut partager des cookies avec le domaine de la SPA, aucun jeton n’est nécessaire. OAuth ajoute des vecteurs d’attaque supplémentaires sans apporter de valeur ajoutée et devrait être évité au profit d’une approche traditionnelle fondée sur les cookies.

Lorsque la SPA appelle plusieurs API situées sur un domaine différent, des jetons d’accès et, éventuellement, des jetons d’actualisation sont nécessaires.

• Si le backend de la SPA peut gérer les appels d’API, il fonctionne alors de façon semblable à une application web traditionnelle qui gère les jetons côté serveur à l’aide de :

  • Authorization Code Flow
  • Authorization Code Flow with Proof Key for Code Exchange

• Si le backend de la SPA ne peut pas gérer les appels d’API, il fonctionne alors de façon semblable à une application mobile qui stocke les jetons dans le backend de la SPA, mais la SPA doit récupérer les jetons depuis le backend pour effectuer des requêtes vers l’API. Un protocole doit être établi entre le backend et la SPA pour permettre le transfert sécurisé du jeton du backend vers la SPA.

• Si vous avez une SPA sans serveur backend correspondant, votre SPA devrait demander de nouveaux jetons lors de la connexion et les stocker en mémoire sans aucune persistance. Pour effectuer des appels d’API, votre SPA utiliserait alors la copie en mémoire du jeton.

Conformément aux spécifications OAuth2, lorsqu’un navigateur demande un jeton d’actualisation au endpoint /token, Auth0 ne renverra un Refresh Token que si la Refresh Token Rotation est activée pour ce client.

Pour plus de détails, consultez Auth0 SPA SDK dans Github.

​

Scénarios de stockage en mémoire dans le navigateur

Auth0 recommande de stocker les jetons dans la mémoire du navigateur, car c’est l’option la plus sécuritaire. L’utilisation de Web Workers pour gérer la transmission et le stockage des jetons est la meilleure façon de les protéger, puisque les Web Workers s’exécutent dans un contexte global distinct de celui du reste de l’application. Utilisez Auth0 SPA SDK, dont l’option de stockage par défaut est le stockage en mémoire tirant parti des Web Workers.

Si vous ne pouvez pas utiliser les Web Workers, Auth0 recommande plutôt d’utiliser des closures Javascript pour émuler des méthodes privées.

Utilisez Auth0 SPA SDK, dont l’option de stockage par défaut est le stockage en mémoire, afin de tirer parti à la fois des Web Workers et des closures Javascript selon le type de jeton.

La méthode de stockage en mémoire dans le navigateur n’offre pas de persistance entre les actualisations de la page ni d’un onglet du navigateur à l’autre.

​

Scénarios liés au stockage local dans le navigateur

L’utilisation du stockage local dans le navigateur peut constituer une solution de rechange viable aux mécanismes qui exigent de récupérer le jeton d’accès à partir d’un iframe, ainsi qu’à l’authentification fondée sur des cookies entre domaines, lorsque ces options ne sont pas possibles en raison des restrictions du navigateur (par exemple, ITP2).

Le stockage de jetons dans le stockage local du navigateur permet de les conserver entre les actualisations de page et d’un onglet à l’autre. Cependant, si un attaquant parvient à exécuter du Javascript dans la SPA au moyen d’une attaque de script intersite (XSS), il peut récupérer les jetons stockés dans le stockage local. Une vulnérabilité menant à une attaque XSS réussie peut se trouver soit dans le code source de la SPA, soit dans n’importe quel code Javascript tiers (comme Bootstrap, jQuery ou Google Analytics) inclus dans la SPA.

Pour réduire les risques de sécurité si votre SPA utilise le flux Implicit (nous recommandons plutôt d’utiliser le flux d’autorisation par code avec PKCE) ou des flux hybrides, vous pouvez réduire la durée d’expiration absolue du jeton. Cela réduit l’impact d’une attaque XSS réfléchie (mais pas d’une attaque persistante). Pour réduire la durée d’expiration, accédez à Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds).

Réduisez au minimum la quantité de code Javascript tiers provenant d’une source externe à votre domaine (comme des liens vers jQuery, Bootstrap, Google Analytics, etc.). Réduire la quantité de code JS tiers diminue le risque de vulnérabilité XSS. Il est aussi plus sécuritaire d’effectuer une vérification de Subresource Integrity (SRI) dans les scripts tiers (lorsque possible) afin de vérifier que les ressources récupérées sont livrées sans modification inattendue.

​

En savoir plus

• Jetons d’identité
• Jetons d’accès
• Jetons d’actualisation
• Bonnes pratiques pour les jetons