JWT (JSON Web Token / jwt decoder / jwt online / decode jwt) n est pas du chiffrement, c est de l encodage — le payload utilise base64url qui decode en texte clair en une seconde, donc ne mettez jamais de mots de passe / PII / cartes bancaires / numeros de telephone dans le payload JWT. Cet article couvre 8 foot-guns reels de securite JWT + 5 scenarios d attaque de falsification + plan de protection 7 jours, qui ensemble evitent au moins 90% des vulnerabilites.

Resume en 30 Secondes

  • JWT n est pas du chiffrement, c est de l encodage — beaucoup de developpeurs pensent que JWT est “sur” parce que l encodage base64url semble illisible, mais n importe qui peut decoder en une seconde pour obtenir le payload en texte clair. JWT payload = texte clair, seulement signe, pas chiffre
  • JWT standard 4 risques principaux : attaque alg=none / confusion cle publique HS256 vs RS256 / exp non valide donc tokens expires passent / suppression signature certaines bibliotheques acceptent comme fallback
  • Deploiement JWT 4 foot-guns : JWT secret hardcode dans Git scanne en quelques heures / injection kid n importe quel fichier utilise comme cle / pas de blacklist vieux tokens valides apres logout / expiration longue (7 jours) changement mot de passe n invalide pas les tokens
  • 5 scenarios d attaque reels : fuite telephone texte clair / falsification alg=none / signature HS256 avec cle publique / exp non valide / suppression signature passe validation
  • Plan de protection 7 jours (chacun ≤ 30 minutes) : forcer whitelist algorithme (toujours verifier exp) / JWT secret via env vars + .gitignore / validation stricte format kid (whitelist caracteres) / signature doit verifier (none rejete) / expiration courte (15 minutes) + rotation refresh token / blacklist + etat revoke en BD / jamais mettre PII dans payload JWT
  • Utilisez le Decodeur JWT Piick localement pour decoder les tokens suspects et verifier header / payload / exp / signature — 100% local sans telechargement, ne pollue pas votre log d audit pendant le debug

8 Foot-Guns Reels de JWT

Foot-Gun 1 : JWT N Est Pas du Chiffrement, C Est de l Encodage

Symptome : Vous mettez le numero de telephone / email / 4 derniers chiffres de carte / hash d identifiant de l utilisateur dans le payload JWT, en pensant “le token ressemble a du texte illisible, les autres ne peuvent pas le lire”. Jusqu au jour ou le payload fuite, base64url decode — telephone + email + hash d ID en texte clair tout expose, amende de conformite GDPR a partir de ¥500k.

Pourquoi : JWT a trois segments header.payload.signature, seule la signature est signee (HMAC/RSA signee pour empecher la falsification), mais le payload lui-meme est en texte clair encode avec base64url. N importe qui avec le token (y compris logs frontend / CDN / proxy inverse / DevTools du navigateur) peut atob(token.split('.')[1]) decoder en JSON en une seconde. JWT n est pas du chiffrement, c est du “texte clair inviolable”.

Correction :

  • Ne mettez jamais de PII (Informations Personnellement Identifiables) dans le payload JWT — pas de telephone / email / carte d identite / carte bancaire / adresse / hash de mot de passe
  • Le payload JWT ne contient que des “identifiants non sensibles” — user_id (UUID de base de donnees, pas nombre derivable), role (role, pas structure organisationnelle), exp / iat / nbf (timestamps)
  • Champs vraiment sensibles : mettez-les dans la base de donnees du backend, le JWT n a que user_id, interrogez la BD quand necessaire
  • Si vous avez vraiment besoin de donnees sensibles dans le token : utilisez JWE (JSON Web Encryption) — mais 99% des scenarios n en ont pas besoin

Scenario reel : Une entreprise SaaS a mis les numeros de telephone des utilisateurs directement dans le payload JWT (pour “economiser une requete de base de donnees”), 3 mois plus tard le JWT secret a fuit, 2 millions de telephones d utilisateurs obtenus en un clic via le decodage du payload, amendes doubles GDPR + Loi chinoise sur la Protection des Informations Personnelles ¥8 millions.

Foot-Gun 2 : Attaque alg=none

Symptome : Votre bibliotheque JWT est ancienne (jwt-go version ancienne / jsonwebtoken avant 4.x / python-jose vieille version), un attaquant construit header = {"alg": "none"} + payload arbitraire, forge un token admin, votre bibliotheque serveur accepte, l attaquant obtient directement les privileges admin.

Pourquoi : Le standard JWT ancien RFC 7519 n exigeait pas la validation cote serveur du champ alg, certaines bibliotheques voyant alg: "none" font confiance directement au payload sans verifier la signature (parce que “none” = “pas de signature”, la bibliotheque saute l etape de verification). C est l attaque la plus classique de l histoire de JWT, en 2015 Auth0 et plusieurs autres bibliotheques ont ete touchees.

Correction :

  • Forcer la whitelist d algorithme (specifiez toujours les algorithmes autorises) : jsonwebtoken.verify avec whitelist d algorithmes : [‘HS256’]
  • Toujours rejeter alg: "none" (meme si compatible RFC)
  • Mettre a jour vers la derniere version de la bibliotheque JWT (corrige les vulnerabilites connues d alg=none)
  • Revue de code verifiant les appels verify — pas de parametre d algorithmes specifie = vulnerabilite

Scenario reel : Rapport public Auth0 2015 : la bibliotheque Node.js jsonwebtoken versions avant 4.2.2 acceptent alg: "none" par defaut, tout serveur acceptant des tokens sans mise a jour etait sous attaque. Apres le correctif toutes les bibliotheques modernes exigent de specifier les algorithmes.

Foot-Gun 3 : Attaque de Confusion de Cle Publique HS256 vs RS256

Symptome : Vous utilisez RS256 (RSA asymetrique), cle publique placee sur le frontend / gateway pour verifier les tokens, mais un developpeur a ecrit la fonction verify, voyant le header alg: "HS256" utilise la meme cle publique comme secret HMAC pour verifier. L attaquant obtient la cle publique (deja publique) → utilise la cle publique comme secret HMAC pour signer un token HS256 → le serveur utilise la meme cle publique pour “verifier”, passe → token admin faux contourne l authentification.

Pourquoi : RS256 utilise la cle privee RSA pour signer, la cle publique pour verifier ; HS256 utilise le meme secret a la fois pour signer et verifier. Si le code serveur confond “j ai une cle, je l utilise”, l attaquant peut utiliser n importe quel type de cle pour forger des tokens. C est la vulnerabilite la plus classique du deploiement RS256.

Correction :

  • Toujours forcer que l alg du header corresponde a l algorithme configure — algorithme ecrit dans la config (service RS256 verifie toujours alg=RS256 attendu)
  • secret / cle publique avec noms strictement separes (eviter la confusion) : const JWT_PRIVATE_KEY = …; // uniquement pour signer const JWT_PUBLIC_KEY = …; // uniquement pour verifier
  • Revue de code verifiant la fonction verify — forcer la liste d algorithmes verify (whitelist), ne pas accepter l alg auto-declare du token
  • Utilisez des bibliotheques JWT matures (PyJWT / jsonwebtoken / java-jwt) plutot que d implementer verify vous-meme

Scenario reel : En 2018 le service de gateway JWT d une banque utilisait RS256, mais la fonction verify avait un bug d implementation : jwt.verify(token, publicKey) ne specifiait pas les algorithmes, l attaquant a utilise la cle publique comme secret HMAC pour signer un token HS256 passant la verification, a forge un transfert de $10 millions.

Foot-Gun 4 : Champ exp Non Valide ou Validation Fuitee

Symptome : Votre JWT a un champ exp (temps d expiration), en supposant la validation automatique, mais certains chemins de code marginaux du serveur ne verifient que la signature pas exp (par exemple, un chemin de fallback), les tokens expires sont toujours acceptes, la session n expire jamais. L utilisateur change son mot de passe / est desactive / se deconnecte, le token reste utilisable jusqu a ce que exp expire.

Pourquoi : Le standard JWT RFC 7519 § 4.1.4 specifie que exp est MUST validate, mais beaucoup de bibliotheques ne forcent pas la validation d exp par defaut (pour la compatibilite avec certains scenarios comme “tokens permanents”). Si l appel verify ne passe pas explicitement ignoreExpiration: false ou ne verifie pas manuellement dans le code au lieu d utiliser la bibliotheque, exp est ignore.

Correction :

  • Toujours verifier exp explicitement (ne pas se fier aux valeurs par defaut) : jwt.verify avec algorithms : [‘HS256’] et ignoreExpiration : false
  • Temps d expiration court (access token 15 minutes, refresh token 7-30 jours)
  • horloge du serveur synchronisee avec NTP (eviter le decalage d horloge qui cause l expiration prematuree / tardive du token)
  • Le client ne doit pas faire confiance a l heure locale — utilisez Date.now() / time.time() et l heure du serveur pour calculer la difference d exp

Scenario reel : L expiration de l access token d un service SaaS etait de 7 jours, un utilisateur a change son mot de passe mais l attaquant a utilise l ancien token, a pu acceder a toutes les ressources de l utilisateur pendant 7 jours. Raccourcir a 15 minutes + rotation du refresh token est le standard de l industrie.

Foot-Gun 5 : Fuite de JWT Secret / Cle Privee Hardcodee dans Git

Symptome : Vous ecrivez `const JWT_SECRET=*** dans le code + commit + push vers GitHub (meme depot prive, depart d employe / vol de compte / fuite interne). Le secret scanning de GitHub scanne en 30 secondes, le JWT secret fuit comme les cles API, l attaquant utilise ce secret pour signer des tokens pour n importe quel utilisateur n importe quel payload, tout le systeme est compromis.

Pourquoi : L historique Git ne supprime jamais (git filter-branch ne change que le pointeur de branche, les anciens objets commit restent dans .git/objects/ pendant 30 jours). Le JWT secret est du meme niveau de desastre que la cle API apres la fuite — l attaquant obtient le secret = tout le systeme d authentification compromis = identite utilisateur arbitrairement forgee.

Correction :

  • JWT secret via env vars + .gitignore : const JWT_SECRET=*** Ne jamais hardcoder dans le code
  • CI utilise OIDC / tokens court terme, pas de secrets long terme
  • JWT secret comme rotation + surveillance des cles API — le plan de protection 7 jours de batch-24 api-key-leak-prevention s applique completement

Scenario reel : Une entreprise fintech jwt-secret ecrit dans config/default.json commite dans GitHub, le secret scanning de GitHub 30 secondes email + webhook a l attaquant, en 1 heure 2 millions de JWT d utilisateurs re-signes, soldes des utilisateurs arbitrairement modifies. Correction : deplacer le secret vers Vault / AWS Secrets Manager + CI OIDC.

Foot-Gun 6 : Attaque d Injection kid (Key ID)

Symptome : Vous utilisez l architecture RS256 multi-cles, le champ kid du header specifie quelle cle publique utiliser, le serveur getKey(header.kid) consulte la table des cles publiques basee sur kid. L attaquant construit kid: "../../etc/passwd" ou kid: "' OR 1=1--", certaines bibliotheques JWT directement fs.readFileSync(getKey(kid)) ou concatenent une requete SQL, causant une lecture de fichier arbitraire / injection SQL.

Pourquoi : Le champ kid est cense etre “quelle cle utiliser pour la verification”, mais les bibliotheques implementant getKey traitent souvent kid comme nom de fichier / parametre SQL / chemin URL, sans validation de caracteres whitelist. L attaquant utilise kid pour du path traversal (LFI / RCE) ou injection SQL.

Correction :

  • kid whitelist stricte de caracteres (autoriser uniquement [A-Za-z0-9_-]) : valider kid avec regex whitelist (alphanumerique + tiret + underscore, 1-32 caracteres)
  • La valeur kid doit etre dans l ensemble de cles connu (verification Map.has(kid))
  • Ne pas traiter kid comme nom de fichier / parametre SQL / chemin URL
  • Utilisez des bibliotheques JWT matures (implementer getKey vous-meme est propice aux bugs)

Scenario reel : Node.js jsonwebtoken + certains plugins supportent le champ jwk du header, l attaquant construit jwk: [objet avec cle controlee par l attaquant], fait que le serveur utilise la cle fournie par l attaquant pour verifier = definitivement passe. Correction : rejeter les champs jwk / jku / x5u propres au token, utiliser uniquement la cle configuree sur le serveur.

Foot-Gun 7 : Attaque de Suppression de Signature

Symptome : Quand vous ecrivez la fonction verify, si certaines conditions limites (par exemple, header.alg ne correspond pas a la whitelist) ne sont pas gerees, certaines bibliotheques tombent en acceptant le token sans signature (header.payload. suivi d une chaine vide). L attaquant modifie le payload (par exemple, change role en admin) → supprime la signature → un chemin de fallback saute la verification de signature → token faux passe la validation.

Pourquoi : Le format JWT est header.payload.signature, si seul header.payload. est passe, la bibliotheque analyse le segment de signature comme vide, certaines implementations if (!signature) return payload (parce que “pas de signature = pas besoin de verifier”), contourne toute la verification de signature.

Correction :

  • Toujours verifier les 3 segments complets (header.payload.signature tous doivent avoir du contenu)
  • Rejeter les tokens avec signature vide (meme si compatible RFC)
  • Toujours utiliser des bibliotheques matures (ne pas split + verifier vous-meme)
  • Cas de test : construire header.payload. soumettre, doit etre rejete

Scenario reel : Bug d implementation d une bibliotheque JWT : quand la signature est vide directement return payload, l attaquant capture un token valide → modifie le payload (role → admin) → supprime la signature → passe la validation → obtient les privileges admin. Correction : avant verify verifier token.split(’.‘).length === 3 et le troisieme segment non vide.

Foot-Gun 8 : La Liste de Revocation JWT N Existe Pas

Symptome : L utilisateur change son mot de passe / est desactive par l admin / se deconnecte activement, l ancien token reste valide jusqu a ce que exp expire. L expiration de l access token de 7 jours signifie que l attaquant utilisant l ancien token peut acceder pendant 7 jours apres le changement de mot de passe. Pas de mecanisme de blacklist / revoke = une fois que le JWT est emis on ne peut plus le gerer.

Pourquoi : JWT est concu pour etre stateless — le serveur ne stocke pas les tokens, il verifie seulement la signature. Bon pour le scalabilite horizontale, mauvais pour la revocation. Si vous voulez “revoquer immediatement ce token”, vous devez avoir une blacklist ou un mecanisme de refresh token.

Correction :

  • Access token a expiration courte + rotation du refresh token : access token : expiration de 15 minutes refresh token : expiration de 7 jours, apres chaque utilisation regenerer un nouveau (rotation, l ancien refresh token est invalide)
  • refresh token stocke en BD + blacklist (marquer le refresh token comme revoque lors du logout)
  • Revoquer tous les refresh tokens lors du changement de mot de passe (forcer re-login)
  • Redis blacklist (les scenarios d acces haute frequence utilisent Redis pour cacher les tokens revoques, TTL = validite restante du token)

Scenario reel : Un utilisateur SaaS a change son mot de passe mais l attaquant a utilise le token vole accede pendant 7 jours → email utilisateur modifie / carte de credit ajoutee → decouvert seulement apres la plainte du service client. Correction : access token 15 minutes + rotation refresh token + changement mot de passe revoque tous les refresh tokens.

5 Scenarios d Attaque Reels

Scenario 1 : Fuite de Telephone en Texte Clair

Symptome : Une API SaaS renvoie un JWT utilisateur contenant {user_id: 123, phone: "13812345678", email: "user@example.com"}, le frontend utilise ce token pour afficher l etat “connecte”. 3 mois plus tard le JWT secret fuit, tous les tokens decodes, 2 millions de telephones + emails utilisateurs obtenus en un lot.

Correction :

  • Le payload JWT ne contient que user_id (UUID, pas nombre derivable)
  • Quand le frontend a besoin d afficher le telephone, utiliser user_id pour appeler l API backend pour consulter (ne pas se fier au decodage du token)
  • Ne jamais mettre de PII dans le payload JWT

Scenario 2 : Token Forge avec alg=none

Symptome : Un service Node.js ancien utilise jsonwebtoken@4.2.1, le verify ne specifie pas les algorithmes, l attaquant construit header = {"alg": "none", "typ": "JWT"} + payload {user_id: 1, role: "admin"} + signature laissee vide, forge directement un token admin passant la validation.

Correction :

  • Forcer la whitelist d algorithmes : jwt.verify(token, secret, { algorithms: ['HS256'] })
  • Mettre a jour jsonwebtoken a la derniere version

Scenario 3 : Attaque de Confusion de Cle Publique HS256

Symptome : Le service JWT d une banque utilise RS256 (cle privee signe, cle publique verifie), cle publique sur le gateway API, fonction verify jwt.verify(token, publicKey) ne specifie pas les algorithmes. L attaquant utilise la cle publique comme secret HMAC pour signer un token HS256, le serveur utilise la cle publique pour “verifier”, passe → token admin faux transfere $10 millions.

Correction :

  • verify forcer la whitelist d algorithmes : jwt.verify(token, publicKey, { algorithms: ['RS256'] })
  • Cle privee / cle publique avec noms strictement separes (eviter la confusion dans getKey)

Scenario 4 : exp Non Valide, Token Expire Toujours Accepte

Symptome : Un service JWT a exp, mais la bibliotheque verify par defaut ignoreExpiration: true (pour la compatibilite avec les “tokens permanents”), tous les tokens expires passent. L utilisateur change son mot de passe mais l attaquant utilise l ancien token reste utilisable pendant 30 jours.

Correction :

  • Verifier exp explicitement : jwt.verify(token, secret, { algorithms: ['HS256'], ignoreExpiration: false })
  • Ne jamais se fier aux valeurs par defaut

Scenario 5 : Attaque de Suppression de Signature

Symptome : Bug d implementation de la bibliotheque verify d un JWT : quand la signature est vide directement return payload. L attaquant capture un token valide → modifie le payload → supprime la signature → header.payload. soumet, contourne la verification de signature.

Correction :

  • Avant verify verifier token.split(’.‘).length === 3 et le troisieme segment non vide
  • Toujours utiliser une bibliotheque JWT mature (split + verifier vous-meme est propice aux bugs)
  • Cas de test : token = "header.payload." doit etre rejete

Plan de Protection 7 Jours

Jour 1 : Forcer la Whitelist d Algorithme

5 minutes. Revue de code verifiant tous les appels verify JWT, assurez-vous de specifier la whitelist d algorithmes :

  • Node.js jsonwebtoken : jwt.verify(token, secret, { algorithms: ['HS256'] })
  • Python PyJWT : jwt.decode(token, secret, algorithms=['HS256'])
  • Java java-jwt : Jwts.parser().verifyWith(key).build().parseSignedClaims(token)
  • Toujours rejeter alg=none

Effet : Attaque alg=none + attaque de confusion HS256/RS256 completement bloquees.

Jour 2 : JWT Secret via Variables d Environnement

30 minutes. Deplacer tous les JWT secret / cle privee des fichiers de code / config vers les variables d environnement :

  • Creer .env.example (placeholder, sans vrai secret, a commiter)
  • .gitignore ajouter .env
  • Code changer vers `const JWT_SECRET=*** CI utilise GitHub Actions secrets + OIDC

Effet : Risque de fuite de JWT secret dans Git reduit a zero.

Jour 3 : Toujours Verifier exp + Expiration Courte

1 heure. Revue de code de tous les appels verify, assurez-vous :

  • ignoreExpiration: false specifie explicitement
  • expiration de l access token ≤ 15 minutes
  • expiration du refresh token ≤ 7 jours
  • rotation du refresh token (regenerer apres chaque utilisation)

Effet : Apres fuite du token maximum 15 minutes accessible, pas 7 jours.

Jour 4 : kid Whitelist Stricte

30 minutes. Revue de code de la fonction getKey, assurez-vous :

  • La valeur kid doit correspondre a ^[A-Za-z0-9_-]{1,32}$
  • La valeur kid doit etre dans l ensemble de cles connu
  • Ne pas traiter kid comme nom de fichier / parametre SQL / chemin URL
  • Rejeter les champs jwk / jku / x5u propres au token (utiliser la cle configuree sur le serveur)

Effet : Attaque d injection kid completement bloquee.

Jour 5 : La Signature Doit Etre Verifiee

15 minutes. Revue de code des pre-verifications verify :

  • token.split(’.‘).length === 3
  • Troisieme segment (signature) non vide
  • Version de la bibliotheque est la derniere (pas de vulnerabilites connues de suppression de signature)
  • Cas de test : token = "header.payload." doit etre rejete

Effet : Attaque de suppression de signature completement bloquee.

Jour 6 : Mecanisme de Revocation du refresh token

Demi journee. Implementer la rotation du refresh token + blacklist :

  • La base de donnees stocke les refresh tokens (associes user_id + device + etat revoked)
  • Apres chaque utilisation du refresh token : generer un nouveau, marquer l ancien comme revoked
  • Detecter un refresh token revoque utilise → revoquer tous les tokens de cet utilisateur (suspicion de token vole)
  • Lors du changement de mot de passe : revoquer tous les refresh tokens, forcer re-login
  • Redis cache l etat revoked (scenarios d acces haute frequence)

Effet : Apres logout / changement de mot de passe / desactivation de compte l ancien token est immediatement invalide.

Jour 7 : Audit du Payload JWT

1 heure. Revue de code de tous les appels sign JWT, assurez-vous que le payload ne contient que des identifiants non sensibles :

  • user_id (UUID, pas nombre derivable)
  • role (role, sans exposer la structure organisationnelle)
  • exp / iat / nbf (timestamps)
  • Ne pas inclure : telephone / email / carte d identite / carte bancaire / hash de mot de passe / adresse

Effet : Meme si le token fuit, les PII ne seront pas exposees.

Decisions de Selection d Outil

Option A : Services JWT Commerciaux (Auth0 / Clerk / Firebase Auth / AWS Cognito)

Meilleur pour : Equipes moyennes-grandes / authentification unifiee multi-produit / conformite stricte (finance / sante).

Avantages : Securite mature / standard OAuth 2.0 + OIDC / rotation refresh token integree / blacklist integree / audit de conformite. Desavantages : Prix eleve (Auth0 MAU > 1000 commence a $240/mois), vendor lock-in, auto-hebergement difficile.

Option B : Auto-implementer avec des Bibliotheques JWT Matures (PyJWT / jsonwebtoken / java-jwt)

Meilleur pour : Individuel / petite equipe / startup / MVP.

Avantages : Gratuit / flexible / totalement controlable / compatible standard. Desavantages : Auto-implementer revoke / rotation (facile a buguer), necessite d implementer le plan de protection 7 jours, pas d audit integre.

Option C : Decodeur JWT Piick

Meilleur pour : Tout scenario de debug / audit / apprentissage.

100% local sans telechargement, particulierement adapte pour verifier les tokens suspects en debug / auditer le payload JWT / apprendre la structure JWT :

  • Decoder header + payload (base64url decodage en un clic, afficher le JSON en texte clair)
  • Parser exp / iat / nbf / aud / iss / sub (afficher le compte a rebours d expiration, marquer en rouge deja expire)
  • Verifier l existence de la signature + l algorithme (alerter sur alg=none)
  • Verification de securite kid / jku / x5u (alerter sur les champs suspects)
  • Ne stocke rien (decodage local, detruit a la fermeture de la page)

Arbre de decision :

  • Moyen-grand / multi-produit / conformite → Option A (Auth0 / Clerk)
  • Individuel / petite equipe / MVP → Option B (bibliotheque mature + plan de protection 7 jours)
  • Tout debug / audit → Option C (Piick decodage local)

Pratiques Recommandees

  • Toujours forcer la whitelist d algorithme JWT (algorithms: ['HS256'] ou ['RS256']), toujours rejeter alg=none
  • Toujours verifier exp (explicite ignoreExpiration: false), access token ≤ 15 minutes
  • Ne jamais mettre de PII dans le payload JWT (pas de telephone / email / carte d identite / carte bancaire)
  • Toujours mettre le JWT secret dans env vars + .gitignore, ne jamais hardcoder dans Git
  • Toujours utiliser une bibliotheque JWT mature (PyJWT / jsonwebtoken / java-jwt), ne pas implementer verify vous-meme
  • Toujours utiliser la rotation du refresh token + blacklist, access token ≤ 15 minutes + refresh token ≤ 7 jours + rotation
  • Toujours kid whitelist de caracteres (autoriser uniquement [A-Za-z0-9_-]), rejeter les champs jwk / jku / x5u propres au token
  • Toujours tester l attaque de suppression de signature : token = "header.payload." doit etre rejete
  • Utilisez Decodeur JWT Piick localement pour decoder les tokens suspects verifier header / payload / exp / signature, ne consomme pas les tokens sans telechargement de log (donnees 100% locales), Formateur JSON Piick embellir la structure JSON du payload JWT valider le schema, Testeur de Regex Piick ecrire une regex pour valider le format des claims JWT (iat est nombre, exp est nombre, sub est UUID), Encodeur/Decodeur URL Piick verifier si l URL de callback OAuth contient un token en query string, Generateur Cron Piick generer la planification de rotation JWT — ensemble de 5 outils couvre tous les scenarios dev JWT en ligne / debug / securite, donnees 100% locales sans telechargement

JWT n est pas du chiffrement c est de l encodage, la signature ne peut qu empecher la falsification elle ne peut pas garder le secret. La vraie “securite JWT” = forcer la whitelist d algorithme + verifier exp + sans PII + secret via env vars + kid whitelist + signature doit verifier + rotation refresh token + blacklist. Ajoutez aux favoris le Decodeur JWT Piick — verification en debug de tokens suspects en 1 minute, dev quotidien ne se souciez plus des fuites JWT.