La comparaison entre JWT et sessions est souvent présentée comme un choix entre moderne et ancien. C’est une mauvaise question. Une session classique garde l’état côté serveur et donne au client un identifiant opaque. Un JWT transporte des claims signés que plusieurs services peuvent vérifier sans consulter un store central. Chaque modèle a des coûts, des avantages et des modes de panne différents.
Les sessions centralisent le contrôle
Avec une session, le client envoie un session ID, souvent dans une cookie. Le serveur récupère l’état associé: utilisateur, expiration, facteurs d’authentification, appareil, permissions. Déconnecter l’utilisateur ou révoquer une session revient à modifier ce store.
Cette centralisation facilite le contrôle immédiat. Elle demande cependant un stockage disponible et rapide, une stratégie de partage entre instances et une bonne configuration de cookies.
JWT distribue la vérification
Un access token signé permet à plusieurs API de vérifier identité et scopes sans appel central à chaque requête. Ce modèle convient aux microservices, aux clients mobiles et aux intégrations entre domaines. La signature apporte l’intégrité et les claims transportent le contexte minimum.
Le revers est la fraîcheur. Si l’état utilisateur change, le token existant peut rester valable jusqu’à son expiration, sauf mécanisme additionnel.
La révocation est le compromis principal
Pour un produit qui exige invalidation immédiate, les sessions sont directes. On supprime ou marque l’entrée. Avec JWT stateless, il faut ajouter une blacklist, une version, une introspection ou des tokens très courts. Le modèle redevient partiellement stateful.
Ce n’est pas un échec de JWT. C’est une propriété à accepter ou à compenser. Le mauvais design consiste à découvrir ce besoin après un incident.
Le type de client influence le choix
Les navigateurs gèrent bien les cookies HttpOnly, Secure et SameSite. Les applications mobiles ou les services backend manipulent souvent plus naturellement des bearer tokens. Les SPA ont un débat plus délicat, car JavaScript, XSS et CSRF changent les risques.
Le choix doit venir du modèle de menace, pas de la mode. Où le secret est-il stocké? Qui peut le lire? Comment l’utilisateur se déconnecte-t-il de tous ses appareils?
Les permissions fraîches peuvent nécessiter une consultation
Si les droits changent fréquemment ou dépendent d’une ressource, les mettre dans un JWT peut être insuffisant. Un service peut vérifier un scope général dans le token, puis consulter l’état actuel pour l’action sensible.
Les sessions font naturellement cette consultation. JWT peut l’ajouter de manière ciblée. Les modèles hybrides sont souvent plus réalistes qu’une pureté théorique.
La scalabilité ne se résume pas à une requête de moins
JWT évite une lecture de session, mais augmente la taille des requêtes et ajoute une gestion de clés. Une session store ajoute un composant, mais simplifie révocation et visibilité. Il faut mesurer dans l’architecture réelle: latence, limites d’en-têtes, disponibilité, caches et erreurs.
Un store de session bien conçu peut scaler très loin. Un système JWT mal conçu peut échouer à cause de tokens énormes ou de rotation de clés improvisée.
L’exploitation a besoin de visibilité
Les sessions permettent souvent de lister appareils et connexions actives. Un modèle JWT stateless demande des logs et événements d’émission pour offrir la même expérience. Si le produit promet “déconnecter tous les appareils”, il faut un état quelque part.
Le support doit comprendre le modèle. Après un changement de mot de passe, que reste-t-il valide? Après une suspension, combien de temps un access token peut-il fonctionner?
Les modèles hybrides sont normaux
Beaucoup d’applications utilisent une session ou un refresh token contrôlé pour la relation longue, puis des access tokens courts pour les API. D’autres gardent des sessions web et utilisent JWT uniquement entre services internes. Ce n’est pas incohérent si les frontières sont documentées.
Il faut savoir qui émet, qui vérifie, comment on révoque, combien de temps chaque credential vit et quelles données il contient. Sans cette carte, le mélange devient une source d’incidents.
Choisissez par propriétés
Les sessions donnent un contrôle central et une révocation simple. JWT apporte portabilité et vérification distribuée. Les deux demandent des protections différentes: cookies et CSRF pour l’un, clés, claims et expiration pour l’autre.
La migration doit accepter une période mixte
Passer de sessions à JWT, ou l’inverse, n’est pas instantané. Pendant un temps, certains clients peuvent porter une cookie de session, d’autres un refresh token, d’autres un access token court. Le serveur doit mesurer ces flux et éviter de déconnecter brutalement les utilisateurs actifs.
Les endpoints de logout, changement de mot de passe et révocation doivent être testés dans les deux modèles pendant la transition. Ce sont précisément les endroits où les hypothèses cachées apparaissent.
Le modèle doit être compréhensible pour le support
Un utilisateur demande souvent pourquoi il est encore connecté sur un appareil ou pourquoi une API refuse soudainement. Le support doit pouvoir expliquer la durée des tokens, l’état de la session longue et l’effet d’une révocation. Une architecture correcte mais opaque crée de la frustration opérationnelle.
La bonne question est donc pratique: quelle propriété est prioritaire pour ce flux? Quand la réponse est claire, le modèle d’authentification cesse d’être une préférence abstraite.