Passer au contenu principal

Vue d’ensemble

Principaux concepts
  • Pour protéger votre application contre les attaques malveillantes, vous devez stocker votre jeton correctement.
  • Passez en revue les scénarios correspondant à chaque type d’application.
  • Décidez quelle méthode est la mieux adaptée à votre technologie.
La sécurisation des applications monopages qui effectuent des appels d’API pose ses propres problèmes. Vous devrez vous assurer que les jetons et autres données sensibles ne sont pas vulnérables à l’injection de code indirecte (XSS) et ne peuvent pas être lus par un JavaScript malveillant. Pour en savoir plus, consultez Manuel JWT et Le Guide ultime de l’Authentification Next.js avec Auth0.

​
Scénarios de sites statiques Next.js

Lorsque vous construisez 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 API.
  3. Lorsque votre application appelle une API hébergée en dehors de votre application Next.js au nom de l’utilisateur.
Si un serveur est accessible, votre application peut gérer les échanges avec Auth0 et établir une session. Toutefois, dans ce schéma, nous n’avons pas de programme dorsal. Tout le travail s’effectue du côté client :
  1. L’utilisateur est redirigé vers Auth0.
  2. Lorsque l’utilisateur est connecté avec succès, il sera redirigé vers l’application.
  3. Le côté client complétera l’échange de code avec Auth0 et récupérera le id_token et le access_token de l’utilisateur, qui seront sauvegardés dans la mémoire.
    Diagramme de stockage en mémoire des meilleures pratiques de stockage de jetons
  • Application Web traditionnelle
  • Application native/mobile
  • Application à page unique
Si votre application utilise un scénario de connexion qui ne nécessite pas d’appel à l’API, seul un jeton d’ID est nécessaire. Il n’est pas nécessaire de le stocker. Vous pouvez le valider et obtenir 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 témoin de session. Le témoin doit être chiffré et avoir une taille maximale de 4 Ko. Si les données à stocker sont volumineuses, le stockage des jetons dans le témoin de session n’est pas une option viable.Utilisez les types de flux suivants dans ces scénarios :

​
Scénarios en mémoire du navigateur

Auth0 recommande de stocker les jetons dans la mémoire du navigateur comme l’option la plus sûre. Utiliser des Web Workers pour gérer la transmission et le stockage des jetons est la meilleure façon de protéger les jetons, car les Web Workers s’exécutent dans une portée globale distincte de celle du reste de l’application. Utilisez la trousse SDK Auth0 pour les applications à page unique (SPA) dont l’option de stockage par défaut est le stockage en mémoire utilisant des Web Workers. Si vous ne pouvez pas utiliser des Web Workers, Auth0 recommande comme alternative d’utiliser des fermetures JavaScript pour émuler des méthodes privées. Utilisez la trousse SDK Auth0 pour les applications à page unique (SPA) dont l’option de stockage par défaut est le stockage en mémoire pour tirer parti à la fois des Web Workers et des fermetures JavaScript en fonction du type de jeton.
La méthode de stockage en mémoire du navigateur n’assure pas la persistance des jetons entre les actualisations de pages et les onglets du navigateur.

​
Scénarios de stockage local dans le navigateur

Utiliser le stockage local du navigateur peut constituer une alternative viable aux mécanismes qui demandent la récupération du jeton d’accès à partir d’un iframe et à l’authentification basée sur des témoins entre domaines lorsque cela n’est pas possible en raison de restrictions du navigateur (par exemple, ITP2).
Le stockage des jetons dans la mémoire locale du navigateur assure la persistance des jetons à travers les actualisations de pages et les onglets du navigateur. Toutefois, si un attaquant parvient à exécuter du JavaScript dans l’application Web monopage (SPA) à l’aide des scripts intersites (XSS), il peut récupérer les jetons stockés dans la mémoire locale. Une vulnérabilité menant à une attaque XSS réussie peut se trouver soit dans le code source de l’application Web monopage (SPA), soit dans tout code JavaScript tiers (tel que 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 vous recommandons d’utiliser plutôt un flux de code d’autorisation avec PKCE) ou hybrides, vous pouvez réduire la durée d’expiration absolue des jetons. Cela réduit l’impact d’une attaque XSS réfléchie (mais pas d’une attaque persistante). Pour réduire le temps d’expiration, allez dans Dashboard > API > Paramètres > Expiration des jetons pour les flux de navigateurs (secondes). Réduisez au minimum la quantité de code JavaScript tiers inclus depuis une source externe à votre domaine (comme les liens vers jQuery, Bootstrap, Google Analytics, etc.). Réduire le code JS tiers diminue la possibilité d’une vulnérabilité XSS. Effectuez une vérification de l’intégrité des sous-ressources (SRI) dans les scripts tiers (lorsque cela est possible) pour vérifier que les ressources récupérées sont livrées sans manipulation imprévue est également plus sécurisées.

​
En savoir plus

⌘I