Un JSON Web Token est souvent utilisé pour transporter des informations entre systèmes. Son format compact peut donner l’impression d’un objet chiffré ou intrinsèquement fiable. Ce n’est pas le cas.
Trois parties, généralement lisibles
Un JWT classique comporte un en-tête, un payload et une signature séparés par des points. Les deux premières parties sont encodées, pas nécessairement chiffrées. N’y placez donc pas un secret en supposant qu’il sera invisible.
Le décodeur JWT et l’inspecteur JWT permettent d’examiner localement les champs lisibles d’un jeton.
Décoder n’est pas vérifier
Afficher le payload prouve uniquement que la chaîne respecte suffisamment le format pour être lue. Pour faire confiance aux claims, une application doit vérifier la signature avec la clé et l’algorithme attendus, puis contrôler les contraintes applicatives.
Expiration, audience et émetteur
Des claims comme exp, nbf, iss ou aud n’ont de valeur que s’ils sont effectivement validés. Accepter un jeton expiré, destiné à une autre audience ou provenant d’un émetteur inattendu peut annuler une partie de la protection recherchée.
Attention aux algorithmes et aux clés
L’application doit imposer les algorithmes autorisés au lieu de faire aveuglément confiance à ce que déclare le jeton. Les clés de signature doivent être protégées et renouvelées selon le contexte.
L’encodeur JWT est utile pour comprendre la structure ou préparer des données de test ; générer un jeton n’équivaut pas à construire un système d’authentification sûr.
JWT n’est qu’une brique
Gestion des sessions, révocation, stockage côté client, CSRF, XSS et durée de vie des jetons restent des décisions d’architecture. Pour la partie identifiants, consultez aussi Mots de passe : génération, robustesse et politiques.
Ce que contient réellement la signature
La signature est calculée à partir des parties encodées du jeton et d’une clé selon l’algorithme choisi. Lorsqu’elle est correctement vérifiée, elle permet de détecter une modification et d’établir que le jeton a été signé par une entité possédant la clé attendue. Elle ne rend pas le payload confidentiel.
Les familles symétriques comme HS256 utilisent un secret partagé ; les familles asymétriques comme RS256 ou ES256 séparent clé privée de signature et clé publique de vérification. Le choix dépend de l’architecture, mais l’application doit toujours imposer ce qu’elle accepte.
Les claims enregistrés doivent être validés, pas seulement affichés
exp indique une expiration, nbf une date avant laquelle le jeton ne devrait pas être accepté, iat son émission, iss son émetteur et aud son audience. Lire ces champs avec l’inspecteur JWT est utile pour comprendre un jeton ; la sécurité vient du code qui les contrôle au moment de l’autorisation.
Prévoyez aussi une petite tolérance d’horloge lorsque plusieurs systèmes participent à la validation, sans transformer cette marge en prolongation excessive de la durée de vie.
Jetons courts et renouvellement
Réduire la durée de vie d’un jeton d’accès limite la fenêtre d’utilisation en cas de vol, mais impose une stratégie de renouvellement. Les refresh tokens, lorsqu’ils existent, doivent être traités comme des secrets de grande valeur, protégés et révocables selon le contexte.
La révocation est justement moins naturelle avec un jeton totalement autonome qu’avec une session conservée côté serveur. Cela ne rend pas JWT mauvais : cela signifie qu’il faut choisir le modèle en connaissance de cause.
Où stocker un jeton dans le navigateur ?
Il n’existe pas de réponse universelle indépendante du modèle de menace. Un stockage accessible à JavaScript est exposé en cas de XSS. Un cookie HttpOnly réduit cet accès mais ramène des considérations de cookies, SameSite et CSRF. Le choix dépend de l’application et de la manière dont elle communique avec son backend.
Ne placez jamais un JWT dans une URL : il peut se retrouver dans l’historique, les logs ou des informations de référence.
Erreurs fréquentes
Parmi les erreurs classiques : accepter un algorithme inattendu, ne pas vérifier iss ou aud, utiliser une clé trop faible, donner une durée de vie excessive, placer des données sensibles dans le payload, ou considérer qu’un rôle déclaré dans un jeton dispense le serveur de contrôler l’autorisation.
Un autre piège consiste à confondre authentification et autorisation. Même avec un jeton parfaitement valide, le serveur doit vérifier que l’utilisateur a le droit d’accéder à la ressource demandée.
Utiliser les outils comme instruments d’inspection
Le décodeur JWT, l’inspecteur JWT et l’encodeur JWT sont utiles pour apprendre, déboguer ou préparer des données de test. Évitez d’y coller des jetons de production sensibles lorsque vous n’avez pas vérifié le contexte de traitement ; dans Bethemesh, les outils concernés sont conçus pour fonctionner localement dans le navigateur.
