Session ou JWT : deux approches, deux visions de l’authentification
Quand on développe des applications web, surtout côté backend ou fullstack, il faut bien comprendre comment on gère l'identité des utilisateurs après la connexion. Et selon le contexte du projet, la bonne stratégie n’est pas toujours la même.
Dans une architecture plus classique, côté serveur, on utilise souvent les sessions. Une fois l’utilisateur connecté, on enregistre ses infos côté serveur, et on lui donne un identifiant de session via un cookie. À chaque nouvelle requête, cet identifiant permet de retrouver son état. Simple, efficace… mais ça suppose que le serveur garde en mémoire toutes les sessions actives, ce qui peut vite devenir un problème quand l’application grandit ou tourne sur plusieurs machines.
À l’inverse, dans des systèmes plus modernes, en particulier distribués ou orientés microservices, on préfère les JWT (JSON Web Tokens). Là, l’utilisateur reçoit un jeton signé dès la connexion, contenant ses infos. Pas besoin de consulter un stockage central à chaque requête : le token suffit pour vérifier qui il est. On gagne en performance et en scalabilité. Mais on perd en contrôle : si un token est compromis, difficile de le désactiver avant qu’il n’expire.
✅ Pour un projet centralisé ou sensible (intranet d’entreprise, application avec déconnexion forcée, etc.), les sessions restent souvent le meilleur choix.
✅ Pour une API publique, une app mobile ou un front en SPA (React, Vue…), les JWT brillent par leur souplesse.
En entretien, il ne suffit pas de dire "l’un est stateful, l’autre stateless". Ce que les recruteurs veulent entendre, c’est que vous comprenez les implications concrètes, les avantages techniques, mais aussi les contraintes métier derrière chaque approche.
---
Je suis Philémon GLOBLÉHI, consultant Java, j'accompagne les entreprises dans leurs projets stratégiques :
- Développement & architecture logiciel
- Modernisation de systèmes legacy
- Conception de microservices robustes
- Coaching & montée en compétences des équipes
Un projet en tête ? Réservez un rendez-vous : https://lnkd.in/ecRArCmt
Ou envoyez-moi un message en DM !
Software Engineer | Digital Transformation Lead | Technical Advisor | Clean code advocate
1 month ago
intéressant.. mais permet moi de rajouter ma couche personnelle,
Je.. l'utilise mais je n'aime pas le jwt ! Pourquoi ?
Simplement parce qu'il souvent mal implémenté par les dev..
- Signature non vérifié côté Backend.
- Clé secrète faible (Le HS256.. c'est prévisible..)
- Token mal stocké côté client Web (un bon token est cookie http only).
- Des données sensibles et personnelles stocké dans le payload (nom, prénoms, rôle, contact.. parfois le profile complet).
- Pas de notion de refresh token (surtout dans les app web )
En gros, le JWT n'est pas sécurisé par défaut.. Sa sécurité dépend entièrement de la façon dont il est mis en œuvre.. ce qui nécessite une supervision plus strict dans certaines environnements.