3 ways to automatically renew a user session per token (JWT)
Authentication by stateless token is common nowadays, but how to automatically renew the validity of this token is not always something you know how to do, this article presents three ways to do it.
👋🏻 For a English version of this article 🇺🇸 : let’s check out at Medium

Introduction

Avec une application Web ou mobile se pose généralement la problématique suivante :

Comment puis-je renouveler la session de mon utilisateur sans que ce dernier n'est manuellement à se reconnecter en utilisant ses identifiants?

Pourquoi ?

Parce que c'est bien plus pratique pour l'expérience utilisateur et que cela améliorera grandement le taux de rebond, cependant il faut garder à l'esprit que pour des actions critiques tel que des modifications de coordonnées utilisateur, vérifier les identifiants peut être nécessaire.

Dans cet article nous allons voir 3 manières permettant d'arriver à cet objectif. Chacune d'elles vient avec ses propres spécificités. La plus pertinente est la troisième méthode mais s'il n'est pas possible de l'utiliser pour X raison, alors la deuxième méthode peut être acceptable sous conditions.

Pour ce qui suit, nous partons du principe que nous utilisons un système d'authentification basé sur la méthode JWT, cette méthode sera détaillée dans un autre article, en attendant le web regorge de réponses très explicites sur le sujet : Google is your friend :).

3 façons de renouveler automatiquement la session d'un utilisateur

1. Ne pas laisser le jeton de session expirer

Une authentification par jeton bien implémentée doit idéalement inclure un paramètre spécifiant un délai d'expiration très court pour le jeton.

Pourquoi ? Et bien parce que plus le temps est restreint, plus cela limite la marge de manœuvre d'un éventuel pirate qui aurait pu intercepter le jeton afin de nuire. En limitant le temps de validité, on limite le nombre d'actions malveillantes peuvent se produirent dans la fenêtre de temps donnée.

Problème : si on retire le délai d'expiration, il suffit qu'une personne vole ce jeton et cela reviendrait à s'être fait voler ses clés d'appartement sans changer la serrure. La personne malveillante a donc un accès plus ou moins illimité au compte.

Cette solution est donc à proscrire.

2. Mettre un délai de validité court et stocker les identifiants de connexion dans un coffre fort.

Cette fois-ci l'astuce consiste à laisser un délai d'expiration court sur le jeton, ce qui limite l'impact d'un détournement de ce dernier.

Il faut donc d'un autre côté, afin de compenser la session qui n'est plus infinie, mettre en place un renouvellement automatique du jeton de session en utilisant les identifiants de l'utilisateur. Cette solution améliore l'expérience utilisateur en ne le forçant pas à se reconnecter manuellement.

Problème : En stockant les identifiants de l'utilisateur dans l'application mobile ou dans quelconque forme de coffre fort Web (Indexed DB, local storage...), on permet à n'importe quelle personne qui réussi à injecter du code malicieux Javascript dans la page (Injection XSS) de voler les identifiant de nos utilisateurs. Et attention : Qui dit identifiants, dit également de nombreux services que les personnes utilisent car malheureusement c'est souvent le même mot de passe sur tous les comptes...

Sur une plateforme mobile en utilisant React Native : Il en va de même car bien que le paradigme mobile et l'API Async Storage évitent les problèmes d'injection XSS, d'autres applications malicieuses peuvent accéder à la base de donnée fichier qui se trouve sur le téléphone. Pour la simple et bonne raison que les données ne sont pas chiffrées dans cette dernière !

Ici des solutions existent en utilisant par exemple l'API de « Secure Storage », qui elle est techniquement sécurisée aux intrusions, mais de manière générale stocker des identifiants clients est une mauvaise pratique.

Cela nous amène à la troisième solution qui est pour moi la plus pérènne et sécurisée.

3. L'utilisation d'un jeton de rafraîchissement et les façons de l'exploiter.

Ce jeton additionnel est en réalité une amélioration de la solution que nous venons de voir. Grâce à lui on peut demander au serveur de renouveller la session en créant un nouveau jeton de connexion, cela sans communiquer les identifiants utilisateurs.

Pourquoi c'est bien ?

  1. Les identifiants utilisateurs ne sont plus stockés et ne transitent plus par le réseau, ce qui signifie que la sécurité augmente drastiquement !
  2. Si un pirate arrive à intercepter un jeton de connexion, ce dernier n'est valable que 3 minutes par exemple, ce qui limite la marge de manoeuvre du pirate.

Comment ça se présente ?

En même temps que l'on authentifie l'utilisateur via la méthode de connexion avec l'identifiant et le mot de passe, on donne un jeton de rafraîchissement valable une seule fois qui permet de regénérer un autre jeton de session et de raffraîchissement.

Lorsque le jeton de session expire, on utile la méthode d'authentification pour obtenir deux nouveaux jetons (un de session et un nouveau de raffraîchissement) mais cette fois, à la place du mot de passe, on utilise le jeton de raffraîchissement pour nous authentifier.

On renouvelle cela de manière infinie ou non, c'est à nous d'en juger. Généralement le jeton de rafraîchissement devrait quand même posséder une valeur d'expiration par mesure de sécurité (3 jours ou une semaine par exemple), mais on peut en décider autrement. Si tel choix est fait : il faut dans ce cas penser à demander une confirmation du mot de passe sur des tâches critiques tel qu'un paiement.

Détecter le renouvellement côté client

L'avantage du JWT est qu'il peut être déchiffré côté client, on peut donc consulter sa date d'expiration sans demander l'avis du serveur. On évite ainsi les appels inutiles en sachant à l'avance le caractère invalide du jeton de session.

Conclusion — TLDR;

Pour aller plus loin on peut également utiliser un « cookie HTTPS Only » sur le web, ce qui permet de prevenir l'accès au jeton de session par les injections XSS.

L'idéal est de faire transiter le moins possible les informations sensibles de l'utilisateur et se baser sur des temps de validité très courts afin de réduire l'impact des attaques de type « man in the middle ».

La solution JWT offre beaucoup de flexibilité en terme de sessions « stateless » et reste un choix solide quand à la manière d'implémenter une session utilisateur.


Si il y a des questions quand à l'implémentation, laissez un commentaire et je donnerais quelques ressources :)