JWT, c’est juste du Base64 dans un manteau — décodez-le en quelques secondes en ligne

Vous regardez une onglet réseau. Il y a une en-tête de requête qui affiche Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c et votre première réaction est : « Qu’est-ce que c’est même ça ? »

Bon news : la plupart de cette chaîne sont simplement du Base64. Ce gros bloc effrayant porte un manteau de trench, prétendant être plus mystérieux qu’il n’est. Enlevons-le.

Ce qu’est réellement un JWT

Un JSON Web Token est composé de trois morceaux Base64url encodés reliés par des points :

• En-tête – l’algorithme et le type de token (par exemple {"alg":"HS256","typ":"JWT"})
• Charge utile – les revendications : ID utilisateur, rôles, expiration, tout ce que le serveur a décidé de stocker
• Signature – la partie qui en réalité impose la sécurité

L’en-tête et le payload sont non chiffrés. Ils sont encodés en Base64url, ce qui signifie que n’importe qui possédant le token peut les lire — sans clé requise. Seul le signature empêche tout tampering : modifier un seul caractère dans le payload invalide le token.

Pour décoder le payload en ce moment : prenez le deuxième morceau (entre les deux points), le collez dans un décodeur Base64 décodeur Base64, et vous verrez du JSON brut. C’est tout. C’est le tour de magie.

Comment décoder un JWT en quelques secondes

La méthode la plus rapide : collez votre token dans le décodeur JWT décodeur JWT sur IOTools. Il sépare les trois parties, décode chacune d’elles et affiche l’en-tête et le payload sous forme de JSON formaté — sans compte, sans configuration, sans « connexion pour débloquer le décodeur ».

Ce que vous verrez immédiatement dans un payload typique :

• sub – sujet (généralement l’ID utilisateur)
• iat – timestamp d’émission (epoch Unix)
• exp – timestamp d’expiration
• iss – émetteur
• Toute revendication personnalisée que votre API a insérée : rôles, permissions, niveau de plan, etc.

Si vous avez simplement besoin de savoir si un token est expiré sans configurer un décodeur complet, le vérificateur d’expiration JWT vérificateur d’expiration JWT lit la revendication et vous indique exactement combien de temps il reste — ou quand il est mort. exp Les trois pièges qui dérangent les développeurs

1. L’expiration que vous avez oubliée de vérifier

Ce champ est simplement un nombre dans le payload — le serveur devrait le valider, mais de nombreux codebases plus anciens ne le font pas, ou ont un bug dans le traitement des fuseaux horaires. Si les utilisateurs sont soudainement déconnectés (ou soudainement connectés pour toujours), décodez le token et comparez

Le exp à l’heure actuelle en Unix. Le vérificateur d’expiration exp le fait en un clic. 2. Confusion sur l’algorithme Le champ de l’en-tête indique à l’interpréteur quel algorithme utiliser. Certains vieux bibliothèques JWT acceptaient

et ignoraient la vérification entièrement — en supprimant la signature et en considérant tout payload comme valide. C’est une attaque connue. Vérifiez toujours que votre bibliothèque impose une liste d’algorithmes spécifiques et rejette

Une autre variante : RS256 (asymétrique) vs HS256 (symétrique). Un attaquant qui connaît votre clé publique peut forger un token en changeant l’en-tête vers alg et en signant avec la clé publique comme secret — si la bibliothèque est naïve sur l’affirmation du champ de l’en-tête. La solution : configurez votre bibliothèque avec un algorithme explicite, et non « ce que dit le token ». {"alg":"none"} 3. Des secrets dans le payload none.

Puisque le payload est encodé en Base64 et non chiffré, tout ce que vous y mettez est lisible par le client (et par tout le monde qui intercepte le token sur HTTP non chiffré, bien que vous utilisiez HTTPS partout, n’est-ce pas ?). Ne mettez pas de mots de passe, des données sensibles (PII) ou des informations internes dans les revendications du JWT. Le payload est destiné à des métadonnées d’authentification — pas un endroit pour stocker des données sensibles. HS256 Décoder un token issu par votre propre application et voir ce qu’il contient. Vous pourriez être surpris par ce que des développeurs précédents ont mis là il y a des années. alg JWT vs Tokens de session : quelle est la différence réelle ?

Le débat perpétuel. Voici une comparaison directe :

JWT

Token de session

Où se trouve l’état

Dans le token (sans état)

	Sur le serveur (dans une base de données ou en mémoire)	Annulation
Difficile — le token est valide jusqu’à	sauf si vous maintenez une liste bloquée	Facile — supprimez simplement l’enregistrement de session
Idéal pour les systèmes distribués ; pas besoin d’un stockage partagé de session	Exige des sessions collées ou un stockage partagé (Redis, etc.) exp Visibilité du payload	Le client peut lire les revendications (non chiffrées)
Évolutivité	Opaque pour le client	Risque de stockage
localStorage est vulnérable aux XSS ; un cookie httpOnly est plus sûr	cookie httpOnly (approche standard)	Taille du token
Plus grande — transporte toutes les revendications en ligne	Petite — juste un ID	Meilleur pour
les APIs, les microservices, l’authentification transversale	les applications web classiques, rendues par le serveur	Ni l’un ni l’autre n’est universellement meilleur. Les JWT brillent quand vous avez besoin d’authentification sans état entre plusieurs services. Les tokens de session sont plus simples quand vous contrôlez l’ensemble de la pile et que vous avez besoin d’annulation instantanée (par exemple, « déconnecter partout » en cas d’incident de sécurité).
Déboguer les JWT dans des workflows réels	Voici la séquence typique lorsque quelque chose va mal dans une API utilisant des JWT :	Copier le token

du requête échouée (en-tête Authorization, paramètre de requête ou cookie — où votre API l’a placé)

Coller dans le

pour voir les revendications brutes

1. — est le token expiré ? Utilisez le si vous ne voulez pas faire de calculs d’horodatage en tête
2. — l’émetteur et l’audience correspondent-ils à ce que votre service attend ? décodeur JWT Vérifiez l’algorithme
3. Vérifiez exp dans l’en-tête — correspond-il à la configuration du serveur ? 2. Confusion sur l’algorithme Vérifiez le format de la signature
4. Vérifiez iss et aud — trois parties ? deux ? Un token corrompu peut apparaître avec deux parties et sans signature
5. La plupart du temps, le débogage des JWT s’arrête à l’étape 3. Le token a été émis avec un TTL court, il a été mis en cache ailleurs, et il est arrivé expiré. C’est ennuyeux et courant. La signature : la seule partie qui compte
6. La signature est calculée comme : . Le serveur la génère lors de l’émission du token. Lors de la validation, il recalculera le même hachage et le comparer. Si le payload a été modifié d’une manière quelconque — même un seul caractère — le hachage ne correspondra pas et le token sera rejeté.

C’est pourquoi décoder un JWT pour lire les revendications est sûr et simple, mais de forger un token sans la clé est impossible. Le Base64 est le costume ; la signature est la clé qui verrouille la porte.

Pour les algorithmes asymétriques (RS256, ES256), la clé de signature est une clé privée qui ne quitte jamais le serveur d’authentification. La clé de vérification est une clé publique que n’importe quel service peut utiliser — aucune clé partagée n’est nécessaire. C’est l’architecture correcte pour les microservices où plusieurs services ont besoin de vérifier les tokens, mais seulement un d’entre eux devrait les émettre.

La signature est calculée comme suit : HMACSHA256(base64url(header) + "." + base64url(payload), secret). Le serveur la génère lors de l'émission du token. Lors de la validation, il recalculer la même hash et la compare. Si le payload a été modifié de quelque manière que ce soit — même un seul caractère — la hash ne correspond pas et le token est rejeté.

C'est pourquoi décoder un JWT pour lire les revendications est sûr et trivial, mais de fabriquer un token sans le secret n'est pas possible. Le Base64 est le costume ; la signature est la clé de la porte.

For asymmetric algorithms (RS256, ES256), the signing key is a private key that never leaves the auth server. The verification key is a public key that any service can use — no shared secret required. This is the right architecture for microservices where multiple services need to verify tokens but only one should issue them.

Vous aimerez peut-être aussi