Qu'est-ce qu'un JWT ? Structure, claims et décodage

Qu'est-ce qu'un JWT

Qu'est-ce qu'un JWT ? Structure, claims et décodeur privé | We.Inc

Les JSON Web Tokens expliqués : header, payload et signature, les sept claims enregistrés de la RFC 7519, les pièges de sécurité, et un décodeur qui n'envoie jamais votre jeton nulle part.

Un JWT (JSON Web Token) est une chaîne compacte et compatible avec les URL, composée de trois parties en base64url séparées par des points : un header qui indique l'algorithme, un payload de claims comme sub et exp, et une signature. N'importe qui peut décoder et lire le payload ; seule la signature, vérifiée avec la bonne clé, prouve que personne ne l'a modifié.

Noms de claims enregistrés (RFC 7519, section 4.1)

Claim
Nom
Signification

Émetteur
Qui a émis le jeton

Sujet
La personne concernée par le jeton, en général un identifiant utilisateur

Audience
Quels destinataires doivent l'accepter

Date d'expiration
Rejeter à partir de cette date

Pas avant
Rejeter avant cette date

Émis le
Date de création du jeton

ID du JWT
Un identifiant unique, utile pour bloquer la réutilisation

Collez un jeton dans le décodeur ci-dessous pour voir son header et son payload, avec chaque claim enregistré expliqué et chaque horodatage converti en date lisible. Le décodage se fait dans le JavaScript de cette page, le jeton n'est donc jamais envoyé. C'est important, car un jeton actif est une clé vers le compte de quelqu'un.

Le décodeur découpe le jeton au niveau des points et attend trois parties (un JWE à cinq parties est chiffré et ne peut pas être lu).
Il reconvertit les deux premières parties de base64url en texte et les analyse comme du JSON.
Les claims enregistrés reçoivent un libellé, et exp, nbf et iat sont affichés sous forme de dates, en indiquant si le jeton est actuellement valide.
La signature est affichée mais pas vérifiée : cela nécessite la clé de l'émetteur, qui a sa place sur votre serveur.

Ne mettez jamais de secrets ni de données personnelles dans un payload. La signature empêche les modifications ; elle ne cache rien.
Fixez les algorithmes que votre serveur accepte. Ne laissez jamais le header alg du jeton décider, et rejetez none.
Vérifiez toujours exp, iss et aud, pas seulement la signature, pour qu'un jeton destiné à un autre service soit refusé.
Les clés HS256 doivent être de longues séquences d'octets aléatoires. La RFC 8725 précise que des mots de passe mémorisables ne doivent pas être utilisés directement.
Gardez des jetons d'accès de courte durée et renouvelez-les, car un JWT volé reste valide jusqu'à son expiration.

Questions fréquentes

Est-il sûr de décoder un JWT en ligne ?

Seulement si le décodage se fait dans votre navigateur. Le jeton est un identifiant : quiconque en détient un valide peut appeler l'API en tant que cet utilisateur jusqu'à son expiration. Le décodeur de cette page s'exécute en local et n'envoie rien, mais pour les jetons de production, le plus sûr est de ne décoder que des jetons de test.

Un JWT est-il chiffré ?

Un JWT signé classique (un JWS) ne l'est pas. Son payload est seulement encodé en base64url, ce que n'importe qui peut inverser. Les jetons chiffrés existent sous forme de JWE, avec cinq parties séparées par des points au lieu de trois, mais la plupart des jetons de connexion et d'API sont signés, pas chiffrés.

Dans quel format sont exp et iat ?

NumericDate : des secondes entières depuis 1970-01-01T00:00:00Z, sans tenir compte des secondes intercalaires. Date.now() en JavaScript renvoie des millisecondes, il faut donc diviser par 1000 avant de comparer, un bug très fréquent.

Faut-il stocker un JWT dans localStorage ou dans un cookie ?

N'importe quel script qui tourne sur la page peut lire localStorage, donc une seule faille de cross-site scripting peut voler le jeton. Un cookie HttpOnly, Secure et SameSite le tient à l'écart des scripts, au prix d'une gestion du CSRF. Beaucoup d'équipes choisissent le cookie pour les sessions navigateur.

Peut-on déconnecter un utilisateur avec un JWT ?

Pas à lui seul, car le jeton reste valide jusqu'à exp. Utilisez une expiration courte avec des refresh tokens révocables, ou tenez une liste de blocage de valeurs jti pour les jetons qui doivent expirer plus tôt.

Les trois parties

Le header est un petit objet JSON comme {"alg":"HS256","typ":"JWT"}. Le payload contient les claims. Chacun est encodé en base64url, c'est-à-dire en base64 avec - et _ à la place de + et /, sans remplissage =, ce qui rend le résultat sûr dans les URL et les en-têtes.
La signature est calculée sur les deux premières parties encodées, jointes par un point. Modifiez un seul caractère du payload et la signature ne correspond plus.

Algorithmes de signature

HS256 utilise un seul secret partagé pour signer et pour vérifier : chaque service qui vérifie des jetons peut donc aussi en créer. RS256 et ES256 signent avec une clé privée et vérifient avec une clé publique, ce qui convient aux architectures où de nombreux services vérifient mais un seul émet.

Les pièges qui causent encore des failles

Les jetons non sécurisés avec alg none ne portent aucune signature. Une bibliothèque qui fait confiance au header peut être trompée et en accepter un, ou traiter une clé RSA publique comme un secret HMAC. La RFC 8725 demande aux bibliothèques de laisser l'appelant fixer les algorithmes autorisés, et c'est ce que vous devez faire.

Décoder et vérifier dans le code

Décoder un payload en JavaScript pur

Lit les claims sans les vérifier. Convient pour afficher un nom d'utilisateur dans l'interface, jamais pour décider d'un accès.

Vérifier côté serveur avec jose

jwtVerify vérifie la signature, exp et nbf, et avec ces options aussi l'émetteur, l'audience et l'algorithme autorisé.

Décodeur JWT privé

Collez un jeton pour lire son header et son payload. Le décodage s'exécute dans votre navigateur ; le jeton n'est ni envoyé, ni stocké, ni journalisé.

Qui a émis le jeton

La personne concernée par le jeton, en général un identifiant utilisateur

Quels destinataires doivent l'accepter

Rejeter à partir de cette date

Rejeter avant cette date

Date de création du jeton

Un identifiant unique, utile pour bloquer la réutilisation

JWT

Charger un jeton d'exemple

Effacer

Header

Payload

Signature (non vérifiée ici)

Claims expliqués

Claim

Valeur

Signification

Claim personnalisé

Un JWT signé comporte 3 parties séparées par des points ; celui-ci en a {n}.

5 parties signifient un JWE chiffré, illisible sans la clé.

La partie {n} n'est pas du JSON base64url valide.

Expiré {v}

Valide jusqu'au {v}

Pas valide avant le {v}

alg vaut none : ce jeton n'a pas de signature et doit être rejeté.

Décodé en local. Rien ne quitte cette page.

Commencer gratuitement · Sans carte bancaire