Encodeur/Décodeur JWT

Encodeur/Décodeur JWT - Créer et Décoder JSON Web Tokens en Ligne

Puissant encodeur et décodeur JWT (JSON Web Token) en ligne permettant créer nouveaux tokens JWT ou décoder, inspecter et comprendre tokens existants instantanément. Encodez header et payload avec signature HMAC (HS256, HS384, HS512), ou décodez header (JOSE header), payload (claims) et signature de tout token JWT. Visualisez claims standards comme émetteur, sujet, audience, date expiration et plus. Parfait pour développeurs, professionnels sécurité et toute personne travaillant avec authentification JWT, OAuth 2.0, OpenID Connect et sécurité API.

Qu'est-ce qu'un JWT et quelle est sa structure?

Un JSON Web Token (JWT, prononcé "jot") est un standard ouvert (RFC 7519) pour représenter des revendications sous forme de chaîne compacte et sûre pour les URLs. Un JWT a trois parties encodées en Base64URL jointes par des points: header.payload.signature. L'en-tête déclare l'algorithme de signature et le type ({"alg":"HS256","typ":"JWT"}). Le payload contient des claims comme sub (sujet), iss (émetteur), exp (expiration) et toute donnée personnalisée. La signature est calculée en hachant l'en-tête+payload encodés avec un secret (HMAC) ou en signant avec une clé privée (RSA/ECDSA). Le token est base64url, pas base64, donc sûr dans les URLs et en-têtes HTTP. Les JWTs sont sans état: le serveur valide la signature à chaque requête sans consulter la base. RFC 7519 est la spécification JWT; RFC 7515 couvre JWS (signé) et RFC 7516 couvre JWE (chiffré).

Qu'est-ce que la vulnérabilité alg=none et comment l'empêcher?

alg=none est la vulnérabilité JWT la plus célèbre, listée dans l'OWASP API Security Top 10. Un token signé avec alg=none n'a aucune signature — mais de nombreuses bibliothèques anciennes l'acceptaient comme "valide" car le champ algorithme de l'en-tête était honoré sans vérification contre une liste blanche. Un attaquant pouvait prendre un token réel, changer l'en-tête en {"alg":"none"}, retirer la signature, modifier le payload (ex. role=admin) et le validateur cassé le laissait passer. La correction est de maintenir une liste blanche stricte d'algorithmes acceptables côté serveur (ex. seulement HS256 ou RS256) et de rejeter tout le reste — ne faites jamais confiance au claim alg du token lui-même. Le bug compagnon est la confusion HS256/RS256: un attaquant soumet un token HS256 signé avec la clé publique RSA du serveur comme secret HMAC. Fixez toujours l'algorithme attendu par clé.

Quelle est la différence entre HS256, RS256 et ES256?

HS256 (HMAC-SHA256) utilise un seul secret partagé pour signer et vérifier — rapide et simple mais toute partie qui peut vérifier peut aussi forger. Utilisez-le seulement quand émetteur et vérificateur sont le même service. RS256 (RSA-SHA256) utilise la cryptographie asymétrique: une clé privée signe, une publique vérifie. C'est le standard pour OAuth/OIDC car les fournisseurs d'identité (Auth0, Okta, Google) publient un endpoint JWKS (JSON Web Key Set) avec des clés publiques que les clients récupèrent pour vérifier les tokens. ES256 (ECDSA P-256) est aussi asymétrique mais utilise les courbes elliptiques, produisant des signatures bien plus courtes (~64 octets vs ~256 octets pour RS256) — mieux pour les scénarios à bande passante limitée. EdDSA (RFC 8037) avec Ed25519 est la recommandation moderne: plus rapide, plus petit et résistant à beaucoup d'attaques temporelles. Évitez RS256 avec des clés sous 2048 bits.

Quels sont les claims enregistrés standard (iss, sub, aud, exp, nbf, iat, jti)?

RFC 7519 définit sept claims enregistrés, tous optionnels mais recommandés. iss (émetteur) identifie qui a créé le token. sub (sujet) est l'ID utilisateur. aud (audience) liste les destinataires prévus — votre service doit rejeter les tokens où son identifiant n'est pas dans aud. exp (expiration) est un timestamp Unix après lequel le token doit être rejeté — gardez-le court (15 min pour les tokens d'accès). nbf (not before) est le moment le plus tôt où le token est valide, utile pour activation programmée. iat (issued at) enregistre quand le token a été créé. jti (JWT ID) est un identifiant unique par token, permet listes de révocation ou détection de rejeu. Tous les claims temporels sont NumericDate (secondes Unix depuis 1970 UTC). Validez toujours exp, nbf, iss et aud — sauter l'un d'eux est un bypass courant.

Où dois-je stocker les JWTs dans le navigateur — cookie ou localStorage?

Aucun n'est parfait. localStorage est vulnérable au XSS: tout script sur votre origine peut le lire et exfiltrer le token. Les cookies sont vulnérables au CSRF s'ils ne sont pas correctement configurés, mais les mitigations sont bien connues. Le motif recommandé par OWASP est des cookies httpOnly + Secure + SameSite=Strict (ou Lax) pour le JWT, combinés à un token CSRF en en-tête pour les requêtes changeant l'état. httpOnly bloque l'accès JavaScript (défait l'exfiltration via XSS), Secure force HTTPS et SameSite limite l'envoi inter-sites. Pour SPA + API sur origines différentes, vous pouvez avoir besoin de SameSite=None; Secure plus CORS explicite. Évitez complètement de stocker des refresh tokens à longue durée dans localStorage. Si vous devez utiliser localStorage, traitez tout XSS comme une prise de contrôle complète de compte et investissez fortement dans les en-têtes Content Security Policy.

Comment fonctionnent les refresh tokens et pourquoi en ai-je besoin?

Les tokens d'accès JWT doivent être de courte durée (5-15 minutes) pour qu'un token divulgué ait une valeur limitée. Mais forcer l'utilisateur à se reconnecter toutes les 15 minutes est une mauvaise UX, donc OAuth 2.0 introduit les refresh tokens — chaînes opaques à longue durée échangées sur l'endpoint /token contre de nouveaux tokens d'accès. Le refresh token est généralement stocké en cookie httpOnly et envoyé seulement au serveur d'auth. Bonnes pratiques: faire tourner les refresh tokens à chaque utilisation (RFC 6749bis), révoquer toute la famille si un token est rejoué (détection de réutilisation), lier les refresh tokens au client (PKCE) et les stocker côté serveur hashés pour qu'une fuite de BD ne les expose pas. Les clients publics (SPAs, apps mobiles) doivent utiliser le flux PKCE. Les refresh tokens sont la cible de haute valeur — protégez-les comme des mots de passe.

Quelle est la différence entre JWT, JWS, JWE et JWK?

Ce sont quatre spécifications liées mais distinctes de la famille JOSE (JSON Object Signing and Encryption). JWS (RFC 7515) est une structure JSON signée — ce que les gens appellent généralement "JWT." JWE (RFC 7516) est une structure chiffrée avec cinq parties (header.encryptedKey.iv.ciphertext.tag) où le payload est caché, pas seulement signé. JWT (RFC 7519) est un format de payload (claims) qui peut être enveloppé dans JWS ou JWE. JWK (RFC 7517) est la représentation JSON d'une clé cryptographique, et JWKS est un ensemble — typiquement publié sur /.well-known/jwks.json par les fournisseurs d'identité. Utilisez JWS quand le payload n'est pas sensible (juste signé pour l'intégrité), utilisez JWE quand le payload doit être confidentiel (ex. contient des PII). La plupart des flux OAuth utilisent JWS, pas JWE.

Quelles informations dois-je éviter de mettre dans un payload JWT?

Les payloads JWT sont encodés en Base64URL, PAS chiffrés — n'importe qui avec le token peut lire chaque claim. Ne mettez jamais de mots de passe, numéros de sécurité sociale, données de carte de crédit, secrets d'API ou toute PII soumise au RGPD/HIPAA/PCI dans un payload JWT sauf si vous utilisez le chiffrement JWE. Évitez aussi de grandes quantités de données: chaque requête transporte le token entier dans l'en-tête Authorization, donc les payloads gonflés gaspillent de la bande passante à chaque appel API. Gardez les claims aux identifiants et scopes d'autorisation (ID utilisateur, rôles, expiration). Pour les recherches sensibles, stockez les données côté serveur indexées par le claim sub. Évitez aussi de mettre des données utilisateur mutables (nom d'affichage, e-mail) qui peuvent changer — le JWT en cache montrera des valeurs obsolètes jusqu'à expiration. Le token est une preuve de capacité, pas un profil utilisateur.

Fonctionnalités Clés

• Décoder tokens JWT instantanément
• Visualiser header (JOSE header) avec algorithme et type token
• Visualiser payload avec tous claims et données custom
• Visualiser signature (encodée base64url)
• Détection automatique claims JWT standards (iss, sub, aud, exp, nbf, iat, jti)
• Formatage timestamp lisible pour claims dates
• Vérificateur statut expiration token
• Support tous algorithmes JWT (HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512)
• Coloration syntaxe et formatage JSON
• Section informations claims avec explications détaillées
• Copier parties décodées presse-papiers
• Télécharger sortie décodée
• Uploader fichiers JWT pour décodage
• Support mode sombre
• Traitement 100% côté client - tokens ne quittent jamais navigateur
• Fonctionne hors ligne après chargement initial
• Aucune limite taille token
• Design responsive adapté mobile
• Messages erreur clairs pour tokens invalides
• Informations éducatives sécurité JWT
• Aucune inscription ou connexion requise