Un JSON Web Token est une chaîne compacte qui transporte des déclarations entre systèmes. On le voit souvent sous la forme de trois segments séparés par des points: header, payload et signature. Les deux premiers segments sont du JSON encodé en Base64URL, tandis que le troisième permet de vérifier que le token n’a pas été modifié. Cette structure a rendu JWT populaire pour les API, mais elle a aussi créé une confusion: un token valide n’est pas automatiquement une autorisation complète.

Le header annonce la méthode de protection

Le header indique généralement le type de token et l’algorithme de signature. Le serveur ne doit pas accepter cette information sans politique. Il doit savoir quels algorithmes sont autorisés pour quel issuer et quelle clé. Laisser le token choisir librement la méthode de validation est une erreur de sécurité.

Des vulnérabilités historiques sont venues d’algorithmes acceptés trop largement ou de confusions entre HMAC et clés asymétriques. La validation commence donc par la configuration du vérificateur, pas par la lecture du payload.

Le payload contient des claims lisibles

Le payload d’un JWT signé n’est pas chiffré. Toute personne qui possède le token peut le décoder et lire ses claims. On y place souvent sub, iss, aud, exp et des scopes. On ne devrait pas y placer de secrets, mots de passe ou informations personnelles inutiles.

La signature protège l’intégrité, pas la confidentialité. Si les claims doivent rester privés, il faut un mécanisme de chiffrement ou un autre modèle de transport.

La signature lie le contenu à une clé

Le producteur signe la représentation exacte du header et du payload. Le consommateur vérifie cette signature avec la clé attendue. Si quelqu’un modifie un claim, la signature ne correspond plus. C’est ce qui permet à plusieurs services de faire confiance à un émetteur commun.

Le modèle de clé change l’architecture. Avec HMAC, les services partagent un secret capable de vérifier et de signer. Avec RSA ou ECDSA, l’émetteur garde la clé privée et les consommateurs utilisent une clé publique.

Les claims enregistrés évitent les ambiguïtés

Un token signé pour un autre public ne devrait pas fonctionner ici. Un token expiré ne devrait pas être accepté. Un token émis par un issuer inconnu ne devrait pas passer, même si sa signature est mathématiquement correcte avec une clé trouvée ailleurs.

Valider iss, aud, exp, nbf et parfois iat fait partie de la validation normale. La signature dit que le contenu n’a pas changé; les claims disent si ce contenu s’applique à cette requête.

L’expiration limite le risque sans tout résoudre

Un JWT d’accès court réduit la fenêtre en cas de vol. Un JWT long ressemble davantage à un mot de passe portable. Comme le token est souvent stateless, le révoquer immédiatement demande un mécanisme supplémentaire: blacklist, version de session, introspection ou rotation de clé.

Beaucoup de systèmes combinent access tokens courts et refresh tokens plus contrôlés. Cette architecture garde de bonnes performances tout en permettant une révocation plus fine.

Le clock skew doit être défini

Les claims temporels dépendent de l’horloge du serveur qui vérifie. Dans un système distribué, quelques secondes d’écart sont possibles. Une petite tolérance évite des rejets légitimes; une tolérance trop grande prolonge inutilement la validité réelle.

La politique doit être uniforme entre services. Les logs devraient distinguer signature invalide, expiration, audience incorrecte et issuer inconnu afin de faciliter le diagnostic.

Le stockage du token change la menace

Un JWT stocké dans localStorage est accessible au JavaScript et donc exposé en cas de XSS. Une cookie HttpOnly réduit ce risque, mais demande une stratégie CSRF et SameSite. Le bon choix dépend du type de client et du modèle de menace.

La taille compte aussi. Des claims trop nombreux augmentent chaque requête et peuvent dépasser des limites d’en-tête. Le token devrait contenir le minimum nécessaire au service consommateur.

Décoder n’est pas faire confiance

Un outil de debug peut afficher le payload, mais cela ne prouve rien sans vérification complète. L’application doit valider signature, algorithme, issuer, audience, expiration, scopes et règles métier. Lire un JWT montre ce qu’il affirme; vérifier décide si l’affirmation est acceptable.

Les identifiants de token aident l’exploitation

Un claim comme jti, lorsqu’il est utilisé, peut relier émission, usage, révocation et diagnostic sans stocker le token complet. Il permet de chercher un événement précis dans les logs, de comprendre une tentative suspecte et de révoquer un jeton ciblé dans les architectures qui le prévoient.

Les logs doivent toutefois rester sobres. Enregistrer le JWT entier transforme les outils d’observabilité en dépôt de credentials. Il vaut mieux journaliser issuer, audience, subject, identifiant de token et raison de validation, avec redaction stricte.

Les claims de permission doivent rester modestes

Un token surchargé de rôles, équipes, préférences et attributs métier devient volumineux et rapidement obsolète. Les claims devraient exprimer ce que le service consommateur doit savoir maintenant, pas toute la fiche utilisateur. Les décisions sensibles peuvent compléter avec une consultation serveur.

Un JWT fonctionne bien lorsqu’il est traité comme un document signé à durée limitée. Il devient dangereux lorsqu’on le prend pour une session auto-suffisante ou un endroit discret pour stocker des secrets.