Passer au contenu principal

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.
  • Examinez 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 ses propres enjeux. Vous devrez vous assurer que les jetons et les autres données sensibles ne sont pas vulnérables aux scripts intersites (XSS) et 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 appelle, au nom de l’utilisateur, une API hébergée à l’extérieur de votre application Next.js
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 côté frontend :
  1. L’utilisateur est redirigé vers Auth0.
  2. Une fois la connexion réussie, il est redirigé vers l’application.
  3. Le côté client effectue l’échange de code avec Auth0 et récupère les id_token et access_token de l’utilisateur, qui sont stockés en mémoire.
    Diagramme des bonnes pratiques de stockage des jetons : stockage en mémoire
Si votre application utilise un scénario de connexion qui ne nécessite pas d’appels d’API, seul un jeton d’identité 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, facultativement, des jetons d’actualisation sont requis. Ils peuvent être stockés côté serveur ou dans un cookie de session. Le cookie doit être chiffré et sa taille maximale est 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 flux suivants dans ces scénarios :

​
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 le SDK SPA d’Auth0, dont l’option de stockage par défaut est le stockage en mémoire au moyen de Web Workers. Si vous ne pouvez pas utiliser les Web Workers, Auth0 recommande comme solution de rechange d’utiliser des closures JavaScript pour simuler des méthodes privées. Utilisez le SDK SPA d’Auth0, 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 de 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 à partir d’un iframe, ainsi qu’à l’authentification fondée sur des témoins entre domaines, lorsque ces options sont impossibles en raison des restrictions du navigateur (par exemple, ITP2).
Le stockage de jetons dans le stockage local du navigateur assure leur persistance lors de l’actualisation des pages et d’un onglet à l’autre. Cependant, si un attaquant parvient à exécuter du JavaScript dans la SPA au moyen d’une attaque de type script intersite (XSS), il peut récupérer les jetons stockés localement. Une vulnérabilité menant à une attaque XSS réussie peut se trouver soit dans le code source de la SPA, soit dans tout 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 des flux implicites (nous recommandons plutôt d’utiliser le flux de code d’autorisation avec PKCE) ou hybrides, vous pouvez réduire la durée de validité absolue du jeton. Cela réduit l’impact d’une attaque XSS réfléchie (mais pas d’une attaque persistante). Pour réduire cette durée, allez à Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds). Réduisez au strict minimum la quantité de code JavaScript tiers inclus à partir d’une source externe à votre domaine (comme des liens vers jQuery, Bootstrap, Google Analytics, etc.). Réduire le code JS tiers diminue le risque de vulnérabilité XSS. Il est également plus sécuritaire d’effectuer une vérification de Subresource Integrity (SRI) sur 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