La gestion sécurisée des jetons d'authentification est essentielle pour la sécurité des applications. La meilleure approche dépend souvent du type d'application (Web, mobile, côté serveur) et du jeton spécifique utilisé (jeton d'accès, jeton d'actualisation).

Voici les principes généraux et les meilleures pratiques pour gérer les jetons d'authentification en toute sécurité :

Principes généraux

• Gardez-les secrets, gardez-les en sécurité : traitez les jetons comme n'importe quelle autre information d'identification sensible. La clé de signature des jetons ne doit être révélée qu'aux services qui en ont besoin.
• Adoptez le protocole HTTPS : transmettez toujours les jetons via des connexions HTTPS sécurisées afin d'éviter toute interception.
• Réduisez au minimum les données sensibles dans la charge utile : n'incluez pas de données utilisateur sensibles dans la charge utile du jeton, car les jetons sont faciles à décoder, même s'ils sont signés.
• Délais d'expiration courts : définissez des délais d'expiration courts pour les jetons d'accès (de quelques minutes à quelques heures) afin de limiter les possibilités d'attaque si un jeton est compromis.
• Évitez le codage en dur : ne codez jamais les jetons en dur et ne les stockez jamais en clair dans l'application.

Stockage des jetons par type d'application

1. Applications Web

• Stockage en mémoire (pour les jetons d'accès dans les SPA) : le stockage des jetons d'accès dans la mémoire du navigateur est considéré comme une option sécurisée, car il atténue les risques associés au stockage dans le système de fichiers. Cela peut être réalisé à l'aide de fermetures JavaScript ou de Web Workers, qui s'exécutent dans un espace global distinct. Cependant, les jetons stockés en mémoire sont perdus lors du rafraîchissement de la page ou de la fermeture de l'onglet.
• Cookies sécurisés HttpOnly (pour les jetons d'actualisation et les applications Web traditionnelles) :
  • Pour les jetons d'actualisation, utilisez des cookies sécurisés HttpOnly avec un attribut SameSite (Lax ou Strict). Les cookies HttpOnly ne sont pas accessibles via JavaScript côté client, ce qui réduit les vecteurs d'attaque XSS.
  • Pour les applications Web traditionnelles rendues par le serveur, il est recommandé de stocker les jetons sur le serveur pour une sécurité maximale. Si le stockage côté client est nécessaire, utilisez des cookies de session cryptés.
• Évitez le stockage local et le stockage de session : ne stockez pas de jetons sensibles dans localStorage ou sessionStorage, car ils sont vulnérables aux attaques de type Cross-Site Scripting (XSS).

2. Applications mobiles (iOS et Android)

• Stockage sécurisé spécifique à la plateforme : utilisez les mécanismes de stockage sécurisé du système d'exploitation.
  • iOS : utilisez Keychain.
  • Android : utilisez KeyStore ou les données internes d'Android.
  • Ces mécanismes sont conçus pour protéger les données sensibles et les jetons contre les autres applications présentes sur l'appareil.

3. Applications côté serveur

• Stockage côté serveur : pour les applications où le backend effectue des appels API, les jetons doivent être stockés sur le serveur. Cela offre le plus haut niveau de sécurité, car les jetons ne sont pas exposés au client.
• Stockage crypté : si les jetons doivent être conservés, cryptez-les au repos dans la base de données ou le système de fichiers.

Meilleures pratiques en matière de gestion des jetons

• Jetons d'actualisation : utilisez des jetons d'actualisation pour obtenir de nouveaux jetons d'accès à courte durée de vie sans que l'utilisateur ait à se réauthentifier fréquemment. Les jetons d'actualisation doivent avoir une longue durée de vie, être stockés de manière sécurisée (par exemple, cookies HttpOnly) et, dans l'idéal, être remplacés après utilisation.
• Révocation des jetons : mettez en œuvre une stratégie de révocation des jetons, en particulier des jetons d'actualisation, en cas de compromission ou de déconnexion de l'utilisateur.
• Réclamations minimales : n'incluez que les réclamations strictement nécessaires dans la charge utile du jeton pour des raisons de performance et de sécurité.
• Décalage horaire : lors de la validation des réclamations basées sur le temps (comme l'expiration), envisagez d'autoriser un léger décalage horaire (quelques secondes) pour tenir compte des différences de temps mineures entre les serveurs.
• Modèle Backend for Frontend (BFF) : pour les applications monopages (SPA), envisagez d'utiliser un modèle Backend for Frontend (BFF) dans lequel le backend gère l'acquisition et le stockage des jetons, agissant comme un intermédiaire sécurisé entre la SPA et le serveur d'authentification.