La méthode d'authentification JWT est un mensonge

JWTs, ou JSON Web Tokens, nous ont vendu un beau mensonge : la promesse d'une authentification sans état. Le discours était élégant. Un serveur vous remet un petit jeton signé lors de la connexion, puis oublie immédiatement tout état de session. Cette merveille autonome signifiait moins de requêtes de base de données, une mise à l'échelle horizontale simplifiée et une empreinte serveur apparemment plus légère. Cela semble formidable, et les gens l'ont cru.

Mais le fondement même de cette promesse s'est effondré sous l'examen. Un jeton sans état véritable ne peut pas être révoqué. Si vous vous déconnectez, si vous êtes banni, ou, plus terrifiant encore, si votre jeton est volé lors d'une violation, il reste parfaitement valide jusqu'à son expiration. Le serveur, de par sa conception, n'a aucun mécanisme pour le « tuer ». Cette vulnérabilité de sécurité fondamentale transforme le rêve sans état en cauchemar.

Le contournement de presque tous les développeurs expose la supercherie. Pour contrer le jeton irrévocable, les gens implémentent une « liste de jetons révoqués » côté serveur. Cette liste, vérifiée à chaque requête, réintroduit l'état de session, annulant complètement le principal avantage du sans état. Comme le souligne si bien « The Boring Auth Method That Actually Works » de Better Stack, vous avez jeté la raison même pour laquelle vous avez choisi les JWT au départ. Vous êtes de nouveau à gérer l'état, mais maintenant avec des étapes supplémentaires et des vulnérabilités inhérentes.

De nombreux développeurs, poursuivant le rêve sans état, commettent une erreur critique : ils stockent leur JWT dans le local storage du navigateur. Cette pratique offre une persistance de session pratique, permettant aux utilisateurs de rester connectés entre les sessions de navigateur sans requêtes serveur supplémentaires. Cependant, cette commodité a un coût de sécurité inacceptable.

Ce choix de stockage apparemment inoffensif crée une porte dérobée béante pour les attaquants. Une vulnérabilité Cross-Site Scripting (XSS) réussie, souvent issue d'une entrée utilisateur non échappée, permet à tout JavaScript malveillant injecté dans la page de s'exécuter avec les mêmes privilèges que l'application légitime. Les gens fourrent ces jetons dans le local storage, les rendant mûrs pour la cueillette.

Une fois qu'un attaquant exécute son script, le JWT stocké dans le local storage est trivial à extraire. Avec le jeton volé, il obtient un accès immédiat et illimité au compte de la victime, contournant tous les mécanismes d'authentification. Ce n'est pas seulement une violation mineure ; c'est une prise de contrôle complète du compte, accordant à l'attaquant les clés de votre royaume numérique.

De manière cruciale, cette catastrophe de sécurité n'est pas une faille dans le standard JWT lui-même. Le problème réside directement dans une erreur d'implémentation répandue et dangereuse. Les développeurs, cherchant une voie facile pour la gestion de session, transforment une primitive cryptographique puissante en une vulnérabilité, donnant aux attaquants les moyens de compromettre les comptes d'utilisateurs par des vecteurs prévisibles.

Une solution à cette blessure JWT auto-infligée est d'une simplicité trompeuse, même « ennuyeuse », comme le décrivent si bien les experts de Better Stack dans « The Boring Auth Method That Actually Works ». Au lieu de jetons complexes et autonomes, nous revenons aux jetons de session opaques : des chaînes de caractères aléatoires et sans signification. Ces jetons agissent simplement comme des pointeurs, se mappant directement à un enregistrement de session riche et modifiable stocké en toute sécurité dans votre base de données côté serveur, restaurant le contrôle que les JWT promettaient d'éliminer.

Cette approche traditionnelle résout instantanément les problèmes critiques qui affligent les JWTs pour la gestion de session. Si un utilisateur se déconnecte, est banni ou si son jeton est volé, le serveur peut immédiatement invalider l'enregistrement de session correspondant, rendant le jeton volé inutile. Surtout, le jeton lui-même ne révèle aucune donnée utilisateur ni aucune revendication d'autorisation ; il s'agit juste d'un identifiant aléatoire, un contraste frappant avec les JWTs riches en informations détaillés dans RFC 7519 - JSON Web Token (JWT). Vous retrouvez une révocation instantanée, une capacité qui manque intrinsèquement aux JWTs sans des contournements maladroits.

De plus, le mécanisme de stockage approprié pour ces jetons opaques élimine le vecteur de vol basé sur XSS dont nous avons discuté. Nous préconisons des cookies HttpOnly sécurisés. Ces cookies sont automatiquement envoyés avec chaque requête mais restent inaccessibles au JavaScript côté client, empêchant les attaquants de les dérober via des vulnérabilités de Cross-Site Scripting. Cette méthode offre une protection robuste côté client, vous redonnant un véritable contrôle côté serveur, une bien meilleure solution que de faire confiance au stockage local côté client.

Les JWTs ne sont pas les méchants ; ils sont juste mal utilisés. Leur véritable pouvoir réside dans des scénarios spécifiques et contraints, et non comme votre gestion de session principale. Employez-les pour des jetons d'accès API de courte durée, accordant des permissions temporaires et granulaires sans consultations constantes de la base de données. Ils excellent dans la communication inter-services, où les systèmes backend échangent des informations fiables et autonomes, tirant enfin parti de leur conception sans état annoncée sans compromis.

L'authentification moderne exige une approche plus intelligente : le modèle hybride. Émettez un jeton de rafraîchissement opaque et sécurisé, une chaîne impossible à deviner, et rangez-le en toute sécurité dans un HttpOnly cookie, le rendant inaccessible aux scripts malveillants côté client. Ce jeton de rafraîchissement robuste distribue ensuite des jetons d'accès JWT ultra-courts directement dans la mémoire de l'application. Ces JWTs éphémères fournissent une autorisation immédiate pour les requêtes, expirant rapidement avant de pouvoir devenir une responsabilité significative, se rafraîchissant de manière transparente en arrière-plan sans intervention de l'utilisateur.

Le paysage de l'authentification poursuit son évolution incessante. Nous allons entièrement au-delà des mots de passe, adoptant les Passkeys et d'autres méthodes sans mot de passe qui offrent une sécurité et une expérience utilisateur supérieures. L'authentification adaptative, qui évalue les facteurs de risque en temps réel, renforce davantage les défenses, rendant l'avenir de la sécurité à la fois plus robuste et moins intrusive pour les utilisateurs légitimes.

Pourquoi le stockage d'un JWT dans le stockage local est-il considéré comme non sécurisé ?

Le stockage des JWTs dans le stockage local les rend vulnérables aux attaques de Cross-Site Scripting (XSS). Tout JavaScript malveillant injecté dans le site web peut accéder au jeton et le voler, permettant à un attaquant d'usurper complètement l'identité de l'utilisateur.

Qu'est-ce qu'un jeton de session opaque ?

Un jeton de session opaque est un identifiant aléatoire et dénué de sens stocké sur le client (idéalement dans un HttpOnly cookie). Il fait référence à un enregistrement de session détaillé stocké dans une base de données côté serveur, permettant une révocation et un contrôle instantanés.

Si les JWTs sont risqués pour les sessions, quels sont leurs cas d'utilisation appropriés ?

Les JWTs sont excellents pour les scénarios sans état et de courte durée, comme la sécurisation des APIs, l'autorisation de la communication de serveur à serveur dans les microservices, ou agissant comme des jetons d'accès temporaires dans un système d'authentification hybride plus complexe.

Peut-on vraiment révoquer un JWT avant son expiration ?

Pas directement. Parce que les JWTs sont sans état, un serveur n'en a aucun souvenir après leur émission. La seule façon d'en 'révoquer' un est de maintenir une blocklist côté serveur, ce qui réintroduit l'état et annule le principal avantage de l'utilisation des JWTs.