Les JSON Web Tokens (JWT) sont omniprésents dans l'authentification moderne des applications web et mobiles. Pouvoir décoder et inspecter un JWT est une compétence essentielle pour tout développeur travaillant avec des API sécurisées, OAuth 2.0, ou OpenID Connect.
Anatomie d'un JWT
Un JWT est composé de trois parties séparées par des points : le Header (algorithme de signature), le Payload (données/claims), et la Signature (vérification d'intégrité). Le Header et le Payload sont encodés en Base64URL, ce qui les rend décodables sans la clé secrète. La Signature nécessite la clé pour être vérifiée.
Cas d'usage
Débogage d'authentification
Inspectez le contenu d'un token pour vérifier les claims (rôles, permissions, expiration) lors du débogage de problèmes d'accès.
Vérification d'expiration
Vérifiez rapidement si un token est expiré en analysant les claims iat (issued at) et exp (expiration).
Analyse de sécurité
Vérifiez que vos tokens ne contiennent pas d'informations sensibles dans le payload (celui-ci est décodable par tous).
Développement d'API
Validez la structure de vos tokens pendant le développement de systèmes d'authentification.
Exemples concrets
| Entrée | Résultat |
|---|---|
| eyJhbGciOiJIUzI1NiJ9... | {"alg":"HS256","typ":"JWT"} |
| Payload avec exp | {"sub":"1234","exp":1700000000} |
Erreurs fréquentes
❌ Stocker des données sensibles dans le JWT
✅ Le payload est décodable par tous (Base64). N'y mettez jamais de mots de passe ou secrets.
❌ Ne pas vérifier l'expiration côté serveur
✅ Vérifiez toujours exp côté serveur, même si le client le fait aussi.
❌ Ignorer l'algorithme "none"
✅ Rejetez toujours les JWT avec alg:"none" côté serveur pour éviter les attaques.
Conseils d'expert
- 💡Le claim "exp" est en timestamp Unix (secondes), pas en millisecondes
- 💡Utilisez des tokens de courte durée (15-30 min) avec un refresh token
- 💡Ne stockez jamais un JWT dans le localStorage en production (préférez httpOnly cookies)
- 💡Vérifiez toujours la signature côté serveur avant de faire confiance au contenu