JWT vs session : quelle authentification choisir ?

JWT vs session : deux façons de se souvenir de l'utilisateur

HTTP n'a aucune mémoire. Chaque requête arrive au serveur comme si c'était la première (y compris celle qui suit de près la précédente). Votre utilisateur vient de saisir son e-mail et son mot de passe ? Encore faut-il le reconnaître à la page suivante, sans lui réclamer ses identifiants à chaque clic.

Voilà tout l'enjeu de l'authentification. On distingue deux grandes familles. Première option : le serveur garde la trace de la connexion et remet au navigateur un simple numéro. Seconde option : il délivre un jeton qui porte lui-même les informations utiles, protégé par une signature. Le débat « jwt vs session » se résume donc à ceci : avec état côté serveur, ou sans état.

Si vous dirigez une entreprise, ne voyez pas là une querelle de développeurs. De ce choix dépendent la sécurité de votre espace client, la facilité à déconnecter un compte compromis et le coût des évolutions futures. Mieux vaut le trancher dès la conception, car il touche à la fois le front end et le back end de l'application.

L'authentification par session : la méthode traditionnelle

Méthode historique des web applications, la session-based authentication équipe encore la plupart des CMS, des boutiques en ligne et des intranets. Son principe tient en quelques étapes, que la documentation anglophone résume souvent d'une phrase : the user logs in, the server creates a session, and the browser stores the session id in a cookie.

Comment fonctionne une session côté serveur

Tout commence quand l'user logs in. Le serveur vérifie alors les credentials, autrement dit l'identifiant et le mot de passe, comparé à sa version hachée. Si tout concorde, le server creates une session : une petite fiche indiquant qui est connecté, avec quels droits et depuis quand. Où la ranger ? Dans la mémoire du serveur, dans un cache ou dans une base de données, où elle reste stored aussi longtemps que nécessaire.

Côté navigateur, on ne reçoit qu'un session id, longue chaîne aléatoire sans signification, logée dans un cookie. Ce cookie repart automatiquement avec chaque request. À réception, the server verifies que l'identifiant existe, retrouve la fiche correspondante et sait aussitôt à qui il a affaire.

Les points forts de la session

Son grand atout ? Le contrôle. L'état de la user session vit sur le serveur, donc vous pouvez le supprimer quand bon vous semble. Un salarié quitte l'entreprise, un mot de passe a fuité, un client signale une activité suspecte : effacez la fiche, et l'accès tombe instantanément.

Autre avantage, la prise en main. Les frameworks web courants gèrent les sessions nativement, avec des options de sécurité éprouvées. Côté cookie, activez HttpOnly, qui le rend illisible pour le JavaScript, Secure, pour qu'il ne circule qu'en HTTPS, et SameSite, qui limite les envois depuis d'autres sites.

Les limites de la session

En contrepartie, le serveur doit stocker et consulter l'état de chaque connexion. Votre application tourne sur plusieurs machines ? Toutes devront alors accéder au même stockage partagé, faute de quoi un utilisateur connecté sur l'une serait un parfait inconnu pour l'autre. Rien d'insurmontable, mais c'est une brique de plus à maintenir.

Pensée pour le navigateur, la session se prête moins bien aux autres usages. Une application mobile ou un partenaire qui consomme votre API sait manipuler des cookies, sans que ce soit toujours naturel. Dernier point : puisque le cookie part tout seul avec chaque requête, prévoyez une protection contre les attaques CSRF, qui cherchent à déclencher une action à l'insu de l'internaute.

• Usage idéal : site web, espace client, back-office, boutique en ligne
• Prise en main : simple, intégrée à la plupart des frameworks
• Sécurité : cookie HttpOnly hors de portée du JavaScript, révocation immédiate
• Limites : état à partager entre serveurs, protection CSRF à prévoir
• Pour qui : la majorité des PME dotées d'un site et d'un espace connecté

Le JWT : un jeton autonome et signé

JSON Web Token : derrière l'acronyme JWT se cache un standard ouvert qui décrit un format de jeton compact. Au lieu de conserver une fiche sur le serveur, on inscrit les informations utiles dans le token lui-même, puis on le signe. Résultat, le serveur n'a rien à stocker pour reconnaître le porteur du jeton.

Ce que contient un JWT

Trois parties séparées par des points composent un JWT. D'abord l'en-tête, qui indique l'algorithme utilisé. Vient ensuite le payload, où figurent les informations, les fameux claims : identifiant de l'utilisateur, rôle, date d'expiration. La signature ferme la marche ; elle est calculée avec une clé secrète que seul le serveur connaît.

Retenez bien ceci : le payload est encodé, pas chiffré. N'importe qui peut le lire en le décodant, donc jamais de donnée sensible à l'intérieur ! La signature, elle, garantit l'intégrité du contenu. Qu'un petit malin s'attribue le rôle « administrateur », et la vérification échoue.

Access token et refresh token

La token based authentication modifie le parcours. À la connexion, le serveur émet un access token, que le client joint ensuite à chaque appel, souvent dans un en-tête Authorization. The server verifies la signature et la date d'expiration sans interroger la moindre base. C'est rapide, et peu importe quel serveur reçoit l'appel.

Un jeton signé reste valable jusqu'à son expiration : on le veut donc short-lived, de l'ordre de quelques minutes plutôt que de plusieurs jours. Pour ne pas redemander le mot de passe à chaque échéance, on lui adjoint un refresh token à durée de vie plus longue. Son unique fonction ? Obtenir un nouvel access token. Lui est stocké et contrôlé côté serveur, justement pour pouvoir être révoqué.

Les limites du JWT

Sa force fait aussi sa faiblesse. Sans état, pas de révocation simple : un jeton volé reste utilisable jusqu'à son expiration, à moins de tenir une liste noire (ce qui réintroduit… un stockage côté serveur). Autre inconvénient, le poids. Les tokens transportent leur payload à chaque requête et pèsent donc plus lourd qu'un simple identifiant.

Reste la mise en œuvre, nettement plus exigeante. Choisir un algorithme sûr, refuser les jetons non signés, gérer la rotation des clés, organiser le renouvellement : une seule erreur de configuration suffit à ouvrir une brèche, comme le rappelle régulièrement le OWASP Top 10.

• Usage idéal : API, applications mobiles, architectures à plusieurs services
• Prise en main : plus exigeante, nombreux réglages de sécurité
• Sécurité : signature infalsifiable, mais révocation difficile sans stockage
• Limites : jeton lisible, taille plus importante, gestion du refresh token
• Pour qui : projets logiciels avec plusieurs clients ou plusieurs serveurs

Comparatif critère par critère

Même besoin, deux philosophies : chaque approche place la confiance à un endroit différent. Passons en revue les critères qui pèsent vraiment sur un projet concret.

Sécurité et vol de jeton

Aucune méthode n'est sûre par nature ; tout se joue à l'implémentation. Mal configurée, une session devient aussi vulnérable qu'un JWT mal signé. Où se situe alors la vraie différence ? Dans la réaction en cas d'incident. Avec une session, vous coupez l'accès sur-le-champ. Avec un JWT, il faut attendre l'expiration, d'où l'intérêt d'une durée très courte et d'un refresh token révocable.

Quelle que soit votre option, les fondamentaux ne changent pas : HTTPS partout, mots de passe protégés par un hachage robuste et, pour les comptes sensibles, une authentification à deux facteurs.

Stockage côté navigateur : cookie ou localStorage

Session cookie contre JWT : l'opposition revient souvent, et elle est trompeuse, car un JWT peut parfaitement voyager dans un cookie. Format et stockage sont deux questions distinctes. Rangé dans le localStorage, un jeton reste lisible par n'importe quel script de la page, si bien qu'une faille XSS suffit à le dérober. Le cookie HttpOnly échappe au JavaScript ; en revanche, il impose de se prémunir contre le CSRF.

Pour une application web, nous vous conseillons de garder l'élément sensible (identifiant de session ou refresh token) dans un cookie HttpOnly, Secure et SameSite. C'est d'ailleurs la recommandation la plus répandue.

Montée en charge et architecture

Là où le JWT brille, c'est quand plusieurs services doivent vérifier l'identité du client sans partager de stockage commun : chacun contrôle la signature, point. La session exige un stockage partagé, que les outils de cache actuels rendent toutefois simple à mettre en place. Pour un site de PME, honnêtement, cet argument pèse rarement dans la balance.

Lequel choisir selon votre cas

Pas de gagnant absolu, donc, seulement un outil adapté à un contexte. Voici notre verdict, situation par situation.

• Votre site, votre espace client ou votre back-office se consulte depuis un navigateur : optez pour la session, plus simple et plus sûre.
• Vous exposez une API à une application mobile ou à des partenaires : misez sur des JWT courts, associés à un refresh token révocable.
• Votre plateforme repose sur plusieurs services indépendants : le JWT leur évite de partager un stockage.
• Vous devez pouvoir bloquer un compte à la seconde, dans la santé ou la finance par exemple : privilégiez la session, ou des jetons très courts.
• Vous hésitez encore ? Partez sur la session, plus facile à sécuriser, et ajoutez des jetons le jour où un vrai besoin apparaît.

Qui se connecte, depuis quel support, avec quel niveau de risque : voilà les questions qui tranchent. Lors d'un projet de création de logiciel, nous réglons ce point dès le cadrage, avant d'écrire la première ligne de code.

Ressources pour aller plus loin

Besoin de vérifier une affirmation ou de briefer votre équipe technique ? Appuyez-vous sur des sources primaires. L'IETF publie la spécification du JWT sous la référence RFC 7519. Du côté de l'OWASP, fondation dédiée à la sécurité applicative, vous trouverez des fiches pratiques sur la gestion des sessions et sur les JSON Web Tokens.

Mozilla, avec sa documentation MDN, explique clairement les attributs des cookies et le fonctionnement de HTTP. Quant aux retours d'expérience de développeurs, très nombreux sur des plateformes comme DEV Community, ils aident à repérer les pièges courants. Gardez toutefois un œil critique : un article de blog reflète un contexte précis, jamais une règle universelle.

Questions fréquentes