JWT Structure DiagramRFC 7519
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsImV4cCI6MTcwOTQwMDAwMH0
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header
Base64URL encoded
Contient le type de jeton (JWT) et l'algorithme de signature (ex: HS256, RS256).
Payload
Base64URL encoded
Contient les revendications (claims) : sub, iac, exp, rôles utilisateur, etc.
Signature
HMAC / RSA signed
Garantit l'intégrité du jeton. Ne peut pas être falsifiée sans la clé secrète.
⚠️
Le Header et le Payload ne sont PAS chiffrés — ils sont simplement encodés en Base64URL. Toute personne possédant le jeton peut les lire. Seule la Signature garantit l'authenticité.
Pourquoi les JWT sont sans état : Le rôle du claim exp
Gestion de session dans les architectures sans état
Contrairement à l'authentification traditionnelle, les JWT sont sans état. Le champ 'exp' est le mécanisme de sécurité le plus important.
Audit local pour une confidentialité maximale
Le vérificateur d'expiration JWT de DevFormat effectue 100% de ses calculs à l'intérieur de votre navigateur.