TK TaskKit
Outils dev

Décodeur JWT

Décode des JSON Web Tokens, inspecte les claims et vérifie l'expiration sans uploader le token.

DécoderEncoder
Token
Décodé

Colle un JWT pour inspecter son header, son payload et ses claims enregistrés.

Token HS256 signé avec le secret "taskkit-demo-secret" — passe en mode Vérifier et colle le secret pour tester la vérification.

Les entrées restent sur cet appareil. Chaque outil dev de TaskKit tourne entièrement dans ton navigateur. Tokens, payloads et texte collé ne sont pas transmis aux serveurs de TaskKit ni à des tiers.

Ce que fait cet outil

Ce décodeur JWT découpe un JSON Web Token en ses trois parties — header, payload et signature — et te montre le contenu décodé avec les claims enregistrés (iss, sub, aud, exp, iat, nbf, jti). La fenêtre de validité est calculée à partir de exp et nbf pour que tu voies d'un coup d'œil si un token est dans les temps.

Il propose aussi la vérification de signature pour les algorithmes que les APIs utilisent vraiment : HS256/384/512 avec un secret partagé, RS256/384/512 et PS256/384/512 avec une clé publique RSA, ES256/384/512 avec une clé publique EC, et EdDSA avec une clé Ed25519. Les clés publiques peuvent être collées comme JWK, comme JWKS complet (TaskKit choisit la bonne clé en faisant correspondre le kid du token), comme bloc PEM SPKI, comme clé publique RSA PEM PKCS#1, comme certificat X.509 (la clé publique est extraite automatiquement) ou — pour EdDSA — comme 64 caractères hex ou 43 caractères base64url. Si le header du token contient un tableau x5c (une chaîne de certificats X.509 inline), le certificat leaf est utilisé automatiquement quand le champ clé est vide.

Quand l'utiliser

  • Inspecter un token renvoyé par ton serveur d'authentification pendant le développement local.
  • Confirmer que les claims d'un token tiers correspondent à ce que ton client attendait.
  • Vérifier qu'un token rafraîchi est signé avec la même clé qu'avant.
  • Vérifier l'expiration quand quelque chose a cessé de marcher exactement à minuit UTC.

Comment ça marche

Le décodage n'est que du Base64URL — la spec JWT utilise du Base64 URL-safe sans padding. Le header et le payload sont du JSON ; la signature est en bytes bruts. La vérification utilise crypto.subtle.verify, l'API WebCrypto intégrée au navigateur, avec l'algorithme tiré du header. EdDSA passe par @noble/ed25519 (aussi 100% navigateur) parce que le support WebCrypto pour Ed25519 reste irrégulier entre navigateurs.

L'entrée de la clé est permissive sur le format. Les clés symétriques (HS*) sont importées en bytes bruts ou en JWK. Les clés asymétriques (RS/PS/ES) sont acceptées en JWK, JWKS (le kid du token choisit la bonne clé — les jeux à clé unique sont utilisés directement), PEM SPKI (BEGIN PUBLIC KEY), clé publique RSA PEM PKCS#1 (BEGIN RSA PUBLIC KEY) ou certificat X.509 (BEGIN CERTIFICATE) — TaskKit parcourt le certificat avec un petit lecteur ASN.1 maison pour extraire le SubjectPublicKeyInfo embarqué. Les clés EdDSA peuvent être un JWK, un JWKS, un SPKI PEM, 64 caractères hex ou 43 caractères base64url.

Rien dans cet outil ne se fait côté serveur. Le token ne quitte jamais ton navigateur, la clé ne quitte jamais ton navigateur, et il n'y a aucune télémétrie sur l'un ou l'autre. Si tu colles un token de production pour déboguer quelque chose, ton auditeur ne verra pas une requête vers taskkit.net qui transporte ce token.

Notes

Pourquoi "alg: none" est-il rejeté même quand le token valide ? Parce qu'aucun JWT du monde réel ne devrait jamais utiliser alg: none. C'est un vecteur d'attaque connu : si ton vérificateur accepte none, un attaquant peut retirer la signature et forger n'importe quel payload. On le remonte comme une erreur plutôt que de l'accepter silencieusement.

Puis-je vérifier un token Microsoft / Google / Auth0 ? Oui — récupère le JWKS de l'émetteur (par exemple https://login.microsoftonline.com/common/discovery/v2.0/keys) et colle tout le document JSON dans le champ clé. TaskKit lit le header kid du token et choisit automatiquement le JWK correspondant ; pas besoin de chercher à la main.

HS256 vs RS256 — lequel utiliser ? RS256 (ou ES256) pour tout ce qu'une partie externe va vérifier, puisqu'il lui suffit de la clé publique. HS256 va bien pour du service à service quand les deux côtés détiennent le même secret.

Mon token a un header x5c — est-ce que ça veut dire que je fais confiance au certificat embarqué ? TaskKit utilisera le certificat leaf de x5c pour vérifier la signature quand tu ne colles pas de clé, pour que tu puisses confirmer que le contenu du token n'a pas été altéré. Il ne valide pas la chaîne jusqu'à une CA — ça nécessite des racines de confiance et c'est hors du périmètre ici. Le chip de résultat affiche « vérifié avec le certificat x5c du header du token (chaîne non validée) » pour que tu ne le confondes pas avec un verdict de confiance bout-en-bout.

Outils liés