Décodeur JWT
Les jetons Web JSON sont constitués de trois segments Base64url : header.payload.signature. Collez un JWT pour lire l'algorithme (alg), l'émetteur (iss), le sujet (sub) et l'expiration (exp) sans envoyer le jeton à un serveur. Ce décodeur ne vérifie pas les signatures : utilisez le secret de votre application ou JWKS pour cela.
JWT token
Output
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "Ada",
"iat": 1516239022
}
}
Comment décoder un JWT
1. Collez la chaîne JWT (format eyJ...).
2. Lire l'en-tête décodé JSON (typ, alg).
3. Lire les revendications de charge utile (sub, exp, rôles).
4. Vérifiez l'expérience par rapport à l'heure actuelle : les jetons expirés échouent à l'authentification API.
Exemples d'inspection JWT
Débogage 401 non autorisé
Décoder le jeton d'accès - l'exp peut être dans le passé en raison d'un décalage d'horloge ou d'un TTL court.
Inspecter OAuth id_token
Afficher les réclamations d'e-mail et de nom renvoyées par le fournisseur d'identité.
Revoir le montage de test
Confirmez que le jeton de test HS256 a la revendication role:admin avant le test d'intégration.
Quand décoder les JWT
• Lors du débogage de l'authentification en développement avec des jetons de test.
• Lors de l'apprentissage de la structure JWT et des revendications standard.
• Lors de la vérification de la charge utile avant de mettre en œuvre les contrôles RBAC.
Limites de sécurité
• Ne collez pas de jetons de production avec des privilèges actifs sur des sites Web non fiables : cet outil est local, mais soyez prudent.
• Lorsque vous avez besoin d'une vérification de signature, utilisez le chiffrement côté serveur avec une clé secrète/publique.
• Lorsque le jeton est crypté, JWE — format différent de celui du JWS en trois parties.
Réclamations enregistrées standard
iss (émetteur), sub (sujet), aud (audience), exp (expiration), nbf (pas avant), iat (émis à), jti (JWT ID). Les revendications personnalisées telles que les rôles ou tenant_id sont spécifiques à l'application.
Algorithmes de signature
HS256 utilise un secret partagé ; RS256 utilise la paire de clés publique/privée RSA. Clés publiques publiées via l'URL JWKS pour vérification.
Désalignement de l'horloge
Les API autorisent souvent une marge de manœuvre de 30 à 60 secondes sur exp/nbf. S'il est valide dans le décodeur mais que l'API est rejetée, vérifiez l'horloge et le fuseau horaire du serveur.
Ne faites jamais confiance uniquement à la charge utile
Décodage côté client pour les astuces de l'interface utilisateur uniquement : les décisions d'autorisation doivent vérifier la signature sur le serveur à chaque demande.
Questions fréquentes
Quelles sont les trois parties JWT ?
En-tête (algorithme et type), charge utile (réclamations), signature (vérification). Séparé par des points.
Le décodage valide-t-il le jeton ?
Non : n'importe qui peut décoder la charge utile ; la signature prouve l'intégrité et l'émetteur.
Qu’est-ce qu’une réclamation d’exp ?
Horodatage Unix en secondes lorsque le jeton expire. Comparez avec l’heure UTC actuelle.
Aucune attaque d’algorithme ?
Les serveurs doivent rejeter alg:none — le décodeur peut toujours afficher l'en-tête pour audit.
Données sensibles dans la charge utile ?
La charge utile JWT n’est pas chiffrée en Base64 — ne saisissez jamais de mots de passe ou de données personnelles inutilement.
Transformation locale ?
Oui — jeton analysé dans le navigateur.
Actualisation ou jeton d'accès ?
Les deux sont souvent des JWT — décodez chacun pour voir les portées et les durées de vie diffèrent.