Décodeur JWT

Qu'est-ce qu'un JWT ?

JWT (JSON Web Token) est un standard ouvert (RFC 7519) pour transmettre de manière sécurisée des informations entre deux parties sous forme d'un objet JSON. Un JWT est compact, autonome (contient toutes les informations nécessaires) et peut être signé pour garantir son intégrité, voire chiffré pour la confidentialité.

Les JWT sont massivement utilisés dans les architectures modernes pour l'authentification (OAuth 2.0, OpenID Connect), l'autorisation API, et l'échange de données entre services. Leur popularité vient de leur stateless nature — le serveur n'a pas besoin de stocker la session, le token contient tout.

Claims JWT courants

• sub: sub (Subject) : identifie le principal — généralement un identifiant utilisateur ou une adresse email.
• iat: iat (Issued At) : horodatage Unix indiquant le moment de création du jeton.
• exp: exp (expiration) : horodatage Unix au-delà duquel le jeton n'est plus valide.
• iss: iss (Issuer) : identifie qui a émis le jeton (par exemple, votre serveur d'authentification).
• aud: aud (Audience) : Identifie le destinataire prévu du jeton (par exemple, votre API).

Comment utiliser cet outil

Collez un JWT dans le champ. L'outil le décode immédiatement et affiche les trois parties séparées : header, payload, signature. Le payload est lisible avec les claims (champs) standard expliqués. Vous pouvez aussi vérifier la signature si vous fournissez le secret.

Considérations de sécurité

Ne stockez jamais d'informations sensibles dans le payload — il est lisible par tous (juste encodé en Base64). Utilisez des secrets forts pour HS256, ou des paires de clés RSA pour les architectures distribuées. Vérifiez TOUJOURS la signature côté serveur. Définissez une expiration courte (15 min) et utilisez des refresh tokens pour la persistence.

Structure d'un JWT

Un JWT contient trois parties séparées par des points : header.payload.signature. Chaque partie est encodée en Base64URL. Le header indique l'algorithme et le type (typiquement undefined). Le payload contient les claims (informations). La signature est calculée sur header.payload avec une clé secrète.

Cette approche est sans état — le serveur n'a pas besoin de stocker les données de session dans une base de données. Toutes les informations nécessaires sont intégrées dans le token lui-même. Cela rend les JWT idéaux pour les systèmes distribués, les architectures microservices et les applications serverless où le partage d'état est difficile à gérer.

Erreurs courantes

Stocker des mots de passe ou données sensibles dans le payload. Accepter l'algorithme 'none' (vulnérabilité critique). Ne pas vérifier l'expiration. Stocker le JWT dans le localStorage (vulnérable XSS) au lieu d'un cookie HttpOnly Secure. Utiliser le même secret pour HS256 entre tous les microservices.

Ne pas implémenter de mécanisme de révocation. Une fois émis, un JWT valide jusqu'à son expiration ne peut pas être révoqué sans une blacklist côté serveur. Pour des sessions sensibles, utilisez des tokens opaques (référence en base) plutôt que des JWT. Vérifier l'audience (aud) pour éviter qu'un token destiné à un service soit utilisé par un autre.

Questions fréquentes

JWT et session : quelle différence ?

Une session traditionnelle stocke l'état côté serveur (ID en cookie, données en base/mémoire). Un JWT est stateless : tout est dans le token. Avantage JWT : pas besoin de stockage serveur, scalabilité horizontale. Inconvénient : pas de révocation immédiate, taille plus importante à chaque requête.

Comment révoquer un JWT ?

Plusieurs approches : 1) Maintenir une blacklist côté serveur (annule le côté stateless), 2) Utiliser des durées de vie très courtes avec refresh tokens, 3) Inclure un identifiant de version dans le payload et l'incrémenter dans la base utilisateur pour invalider tous les tokens précédents.