JWT
Un jeton signé, ses pièges cryptographiques et son défaut irréductible.
Authentification avec JWT
Le JWT est présenté partout comme la solution moderne d'authentification, et cette réputation a une base réelle : un jeton signé permet à n'importe quel service de vérifier une identité sans consulter de base de données ni partager de session. Pour une architecture répartie sur plusieurs services, c'est un gain considérable.
Cette même propriété est aussi son défaut central, et le point sur lequel presque tous les tutoriels restent muets : un JWT ne peut pas être révoqué. Il est valide parce que sa signature est valide, et cette signature reste valide jusqu'à l'expiration inscrite dans le jeton. Si un jeton fuite, si vous licenciez quelqu'un, si un utilisateur change de mot de passe après avoir été compromis, le jeton continue de fonctionner. Une session serveur, elle, se supprime.
Il existe des atténuations — expiration courte, jeton de rafraîchissement, liste de blocage — mais chacune réintroduit une part de l'état que le JWT prétendait supprimer. Choisir le JWT, c'est accepter ce compromis en connaissance de cause, pas éviter une réflexion.
Cette leçon couvre donc le jeton lui-même : sa structure, sa signature, les deux attaques classiques contre les implémentations naïves, son intégration dans Spring Security, et le traitement honnête des questions de stockage côté client et de révocation. Le code utilise Spring Boot 3, Spring Security 6 et Java 17.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion