JWT vs Sessions : quelle stratégie d’authentification pour les applications SaaS modernes ?

Pourquoi les JWT stateless sont souvent un mauvais choix par défaut pour l’authentification SaaS, et dans quels cas les sessions supportées par Redis offrent un meilleur contrôle.

Les JWT sont devenus populaires parce qu’ils promettent une authentification stateless. Le token transporte des informations utilisateur signées, ce qui permet au serveur de vérifier l’identité sans requête base de données à chaque appel.

Cela paraît idéal pour la scalabilité, mais les compromis opérationnels sont souvent sous-estimés dans les produits SaaS. Le principal problème est la révocation : une fois émis, un JWT reste généralement valide jusqu’à son expiration même si le compte doit être désactivé ou si le token est soupçonné d’avoir été compromis.

Les équipes tentent souvent de compenser cette faiblesse avec des listes noires de tokens, des couches de lookup supplémentaires ou des expirations plus courtes. Mais dès lors qu’une infrastructure doit suivre et invalider les tokens actifs, la supposée simplicité du stateless commence à disparaître.

Les sessions traditionnelles supportées par Redis évitent ce problème pour les produits SaaS orientés navigateur. Un store de session en mémoire reste extrêmement rapide tout en donnant au produit un contrôle précis sur le logout, le suivi des appareils, le blocage de comptes et la révocation administrative.

Les JWT conservent tout de même un rôle important. Ils fonctionnent bien pour la communication server-to-server, l’autorisation inter-services et les flux OAuth de courte durée où le stateless apporte une vraie valeur.

Pour les applications SaaS orientées utilisateur final, la bonne question n’est pas quel mécanisme semble le plus moderne. La bonne question est de savoir lequel donne à l’équipe produit les bons leviers de sécurité et la prévisibilité opérationnelle dont le business aura besoin.