Comprendre la structure d'un JWT
Un JSON Web Token (JWT) est un format de jeton compact et sûr pour les URL, défini par la RFC 7519. Chaque JWT se compose de trois parties encodées en Base64URL séparées par des points : l'en-tête, le payload et la signature. L'en-tête déclare l'algorithme utilisé pour signer le token (ex. HS256, RS256, ES256) et le type de token. Le payload contient les claims — des déclarations sur le sujet ou le token lui-même.
Les claims enregistrés standard comprennent `iss` (émetteur), `sub` (sujet), `aud` (audience), `exp` (heure d'expiration sous forme de timestamp Unix), `nbf` (pas avant), `iat` (émis le) et `jti` (identifiant JWT). Les claims privés sont toutes paires clé-valeur supplémentaires dont votre application a besoin, comme les rôles utilisateur ou les identifiants de tenant. Le décodeur présente tous les claims dans une vue JSON lisible accompagnée des octets bruts décodés en Base64URL.
La signature est le troisième segment. Elle est calculée par le serveur émetteur en utilisant l'algorithme déclaré dans l'en-tête et une clé secrète ou privée. La signature garantit que le token n'a pas été altéré en transit. Ce décodeur affiche les octets bruts de la signature mais ne vérifie pas la signature — la vérification nécessite le secret côté serveur ou la clé publique.
Lecture des claims et de l'expiration
Le claim `exp` est une valeur de date numérique représentant les secondes depuis l'époque Unix (1970-01-01T00:00:00Z). Ce décodeur le convertit en horodatage UTC lisible afin que vous puissiez voir instantanément quand le token expire sans calcul manuel. De même, `iat` et `nbf` sont rendus sous forme de dates lisibles.
Le claim `aud` peut être une chaîne ou un tableau de chaînes identifiant les destinataires prévus. Si votre application reçoit un token dont `aud` ne correspond pas à la valeur attendue, le token doit être rejeté. Le décodeur met en évidence le champ audience afin que vous puissiez le vérifier rapidement lors du développement ou du débogage.
De nombreux fournisseurs d'identité intègrent des claims non standard : Azure AD inclut `oid`, `tid` et `roles` ; Auth0 utilise des claims avec espace de noms `https://` ; Cognito ajoute `cognito:groups`. La vue payload affiche chaque claim présent dans le token, vous donnant une visibilité complète sur ce que le fournisseur affirme sans avoir à écrire de code de décodage.
Considérations de sécurité
Décoder un JWT n'est pas la même chose que le valider. Un token décodé vous montre les claims, mais ne prouve pas que le token est authentique ou encore valide. La validation côté serveur doit vérifier la signature par rapport au secret ou à la clé publique, contrôler que `exp` n'est pas dépassé, confirmer que `iss` et `aud` correspondent aux valeurs attendues, et inspecter optionnellement `nbf`. Ne faites jamais confiance aux claims d'un token non vérifié.
Les tokens peuvent être signés (JWS) ou à la fois signés et chiffrés (JWE). Ce décodeur gère les tokens JWS — la forme la plus courante utilisée dans les flux OAuth 2.0 et OpenID Connect. Si vous collez un token JWE (qui a cinq parties séparées par des points), le payload sera un texte chiffré illisible sans la clé de déchiffrement.
Évitez de coller des tokens de production contenant des données utilisateur sensibles dans des outils en ligne. Ce décodeur s'exécute entièrement dans votre navigateur et n'envoie aucune donnée à aucun serveur, le rendant sûr pour le développement local et le débogage. Pour les identifiants de production, préférez des outils CLI comme `jwt-cli` ou du code d'inspection au niveau bibliothèque s'exécutant dans votre propre environnement.