Décodeur JWT

Qu’est-ce qu’un JWT

Un JSON Web Token (JWT, RFC 7519) est une chaîne compacte qui transporte un header et un payload JSON, éventuellement protégés par une signature ou un chiffrement authentifié. La forme signée courante comporte trois segments Base64URL séparés par des points :

base64url(header) . base64url(payload) . base64url(signature)

Le payload inclut typiquement des claims tels que le sujet (sub), l’audience (aud), l’expiration (exp) et des champs applicatifs. Parce que le payload d’un JWT signé (non chiffré) n’est que codé, quiconque obtient le jeton peut lire les claims. La signature détecte la falsification et, avec un secret partagé ou une clé publique, confirme qui a émis le jeton.

Inspectez un jeton d’exemple avec l’outil Décoder JWT—le décodage seul ne prouve pas que la signature est valide.

Sous-outils de cette famille

• Décoder JWT — découpe et décode en Base64URL le header et le payload pour lire algorithmes et claims localement dans le navigateur.
• Signer JWT HS256 — construit un jeton à partir d’un payload JSON et d’un secret partagé via HMAC-SHA256.
• Vérifier JWT HS256 — recalcule la signature HMAC-SHA256 avec votre secret et indique si elle correspond.

Parcours d’apprentissage typique : signer un payload jetable, le décoder pour inspecter les claims, puis vérifier avec le même secret. Modifier un caractère du payload doit faire échouer la vérification.

HS256 et le rôle de HMAC

HS256 signifie HMAC-SHA256 sur les segments header et payload. Émetteur et vérificateur partagent un secret. Ce modèle convient aux API first-party et aux jetons de session simples. Il convient mal lorsque de nombreux clients non fiables doivent vérifier des jetons sans détenir le secret de l’émetteur—là, préférez des algorithmes asymétriques (RS256, ES256) avec un JWKS public.

La vérification HS256 n’est aussi forte que le stockage du secret. Intégrer le secret dans une app mobile publique ou un bundle front-end permet à quiconque de forger des jetons.

Pour la construction MAC sous-jacente, voir aussi le hub HMAC, en particulier HMAC SHA-256.

Claims à traiter avec prudence

exp / nbf / iat. Les fenêtres d’expiration et not-before empêchent une réutilisation indéfinie. Les vérificateurs doivent rejeter les jetons expirés ; les décodeurs qui n’affichent que du JSON n’appliquent pas le temps pour vous.

alg. Le header annonce l’algorithme. Codifiez en dur l’algorithme attendu côté vérificateur (HS256 uniquement, par exemple). Des vulnérabilités historiques acceptaient alg: none ou passaient de RS256 à HS256 en traitant une clé publique comme secret HMAC.

aud et iss. Les contrôles d’audience et d’émetteur empêchent qu’un jeton émis pour un service soit accepté par un autre.

Données sensibles dans le payload. Préférez des identifiants opaques aux données personnelles brutes dans des JWT non chiffrés. Les journaux, l’historique du navigateur et les en-têtes Referer peuvent fuiter des jetons.

Décoder versus vérifier

Vérifiez toujours dans les chemins de code qui autorisent des actions. Décoder dans un débogueur est pour les humains ; la vérification cryptographique est pour les machines qui décident de l’accès.

Détails Base64URL

JWT utilise Base64URL sans padding dans la sérialisation classique. Cela diffère du Base64 standard (+// vs -/_). Mélanger les alphabets en reconstruisant manuellement des jetons est une source fréquente d’erreurs de signature. Préférez des API de bibliothèque qui gèrent l’encodage plutôt qu’une concaténation artisanale en production.

Modes de panne courants

• Décalage d’horloge : un jeton vient d’être émis mais paraît « pas encore valide » ou déjà expiré—autorisez une petite marge si votre plateforme la documente.
• UTF-8 et canonisation JSON : resignater après pretty-print change les octets et casse les signatures.
• Secret différent entre environnements (staging vs production).
• Traiter le succès du décodage comme un succès de connexion.
• Placer des mots de passe ou des données de carte dans les claims JWT.

Limites et environnement

Ces outils se concentrent sur l’apprentissage et le débogage HS256. Ils n’implémentent pas toute la pile JOSE (chiffrement JWE, chaque algorithme JWA ou fédération JWKS). Le traitement côté client garde les jetons d’exemple sur l’appareil ; évitez toutefois de coller des jetons de session de production sur des machines partagées.

Résumé

Les JWT empaquetent des claims dans une chaîne compacte et signée. Ce hub permet de décoder headers et payloads, de signer avec HS256 et de vérifier des signatures HMAC-SHA256. Lisez les claims avec prudence, vérifiez avant de faire confiance, protégez les secrets partagés et choisissez des algorithmes asymétriques lorsque les vérificateurs ne doivent pas partager la clé de l’émetteur.