JWT : les cas où il ne fallait pas

Un utilisateur est licencié à 9 h 02. À 9 h 03, son compte est désactivé dans la console d'administration. À 9 h 40, il télécharge encore l'export des clients. Son token d'accès, signé à 8 h 55 pour une heure, est parfaitement valide : la signature est bonne, l'expiration n'est pas atteinte, et aucune des machines qui le vérifient ne consulte la base où il est écrit que ce compte n'existe plus.

C'est le fonctionnement prévu. Un JWT est une affirmation signée, vérifiable sans interroger son émetteur. Cette propriété fait tout son intérêt, et c'est précisément ce qu'on ne veut pas d'une session.

Ce que « sans état » veut dire quand on doit révoquer

Une session doit pouvoir être tuée, à la déconnexion, au changement de mot de passe, quand un compte est désactivé, un appareil volé ou un utilisateur retiré d'un tenant. Un token autoporteur ne peut pas être tué ; il peut seulement expirer. Tous les montages construits autour du JWT de session tentent de réconcilier ces deux faits.

La durée courte et le refresh token. Le token d'accès vit cinq minutes, et un second token, stocké côté serveur, permet d'en obtenir un nouveau. La révocation prend effet au prochain rafraîchissement. Vous avez maintenant deux tokens, un endpoint de renouvellement, une rotation du refresh token avec détection de réutilisation, et dans le navigateur une file de requêtes à rejouer quand plusieurs onglets rafraîchissent en même temps. Et le refresh token est une ligne dans une table, consultée à chaque renouvellement, autrement dit une session sous un autre nom.

La liste de révocation. Chaque requête vérifie que l'identifiant du token ne figure pas dans une liste noire, soit une lecture par requête dans un stockage partagé. Le bénéfice du « sans état » a disparu, et il vous reste le poids du token, la gestion des clés et les risques de la vérification de signature.