Stockage des jetons
Overview
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 :
Lors de l’accès à une page.
Lors de l’accès à une route API.
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 :
L’utilisateur est redirigé vers Auth0.
Lorsque l’utilisateur est connecté avec succès, il sera redirigé vers l’application.
Le côté client complétera l’échange de code avec Auth0 et récupérera le
id_tokenet leaccess_tokende l’utilisateur, qui seront sauvegardés dans la mémoire.
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 :
Stockez les jetons dans un espace de stockage sécurisé proposé par le système d’exploitation et limitez l’accès à cet espace de stockage. Par exemple, utilisez KeyStore pour Android et KeyChain pour iOS.
Utilisez les types de flux suivants dans ces scénarios :
Flux de code d’autorisation avec Proof Key for Code Exchange
Save and Renew Tokens for Android (Enregistrer et renouveler des jetons pour Android)
Save and Renew Tokens for Swift (Enregistrer et renouveler des jetons pour Swift)
Native/Mobile Apps Quickstarts (Démarrages rapides d’applications natives/mobiles)
Nous vous recommandons d’utiliser la trousse SDK Auth0 pour les applications à page unique (SPA) pour effectuer l’entreposage des jetons, la gestion des sessions et d’autres détails.
Lorsque la SPA ne contacte qu’une API hébergée par un domaine susceptible de partager des témoins avec le domaine de la SPA, aucun jeton n’est nécessaire. OAuth introduit des vecteurs d’attaque supplémentaires sans apporter de valeur ajoutée; il vaut mieux l’éviter en faveur d’une approche traditionnelle basée sur les témoins.
Lorsque la SPA appelle plusieurs API qui résident dans un domaine différent, l’accès aux jetons et, éventuellement, les jetons d’actualisation seront nécessaires.
Si le système dorsal de la SPA peut gérer les appels d’API, il fonctionne de la même façon qu’une application Web traditionnelle qui traite les jetons côté serveur en utilisant :
Si le système dorsal de la SPA ne peut pas gérer les appels d’API, son fonctionnement est similaire à celui d’une application mobile qui stocke les jetons dans le système dorsal de la SPA, mais la SPA doit aller chercher les jetons dans le système dorsal pour effectuer des requêtes à l’API. Un protocole doit être établi entre le système dorsal et la SPA pour permettre le transfert sécurisé du jeton du système dorsal à la SPA.
Si vous avez une application à page unique (SPA) sans serveur dorsal correspondant, votre SPA devrait demander de nouveaux jetons au moment de la connexion et les stocker en mémoire sans aucune persistance. Pour effectuer des appels d’API, votre SPA utilisera alors la copie du jeton en mémoire.
En conformité avec les spécifications OAuth2, lorsqu’un navigateur demande un jeton d’actualisation à partir du point de terminaison /token, Auth0 ne renverra un jeton d’actualisation que si la Rotation des jetons d’actualisation est activée pour ce client.
Pour plus de détails, consultez la trousse SDK Auth0 pour les applications à page unique (SPA) dans GitHub.
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.