01
Comprendre le mode automatique
Le décodage attend 350 ms après une modification. Désactivez-le pour utiliser Décoder ou Ctrl/Cmd+Enter. Ce réglage ne lance jamais la vérification de signature ni la génération de tests.
Inspection des clés publiques
Décodeur JWTavec contrôles distincts de signature et de claims
Lisez le jeton, puis choisissez vous-même les attentes et la clé de vérification.
Décodeur JWT
Jeton JWT
Jeton et clés restent en mémoire dans cette page. Aucune récupération de clé distante ni conservation des entrées.
JSON décodé et rapport
Non vérifié : décoder ne valide pas un jeton.
Paramètres de signature et de claims
Choisissez vous-même l’algorithme attendu. Une signature correspondante ne prouve ni l’identité de l’émetteur, ni les permissions, ni la révocation, ni la validité globale.
Clé publique fournie
Un JWK public ou SPKI PEM PUBLIC KEY. RS256 exige RSA de 2048–8192 bits ; ES256 exige P-256. Clés privées et JWKS distants refusés.
exp, nbf et iat sont contrôlés indépendamment de la signature. Un iat futur est signalé par cet outil. Les dates absentes restent absentes ; émetteur et audience vides ne sont pas contrôlés. UTC est affiché à la milliseconde ; la fraction d’origine reste dans le rapport.
Limites : jeton 100 000 caractères, clé 20 000, claims de test 50 000. Uniquement base64url canonique, UTF-8 et objets JSON. Doublons et nombres altérés par conversion refusés.
Générateur de jetons de test
Collez un JWT compact pour commencer.
Le Décodeur JWT aide à comprendre une requête refusée : consultez l’en-tête, les claims, l’émetteur, l’audience et les dates. Vous pouvez ainsi vérifier si votre application envoie le jeton attendu. La signature affichée au départ reste non vérifiée.
Décoder un JWT permet de lire des données base64url sans clé. La vérification de signature nécessite une clé publique choisie séparément ; l’expiration JWT répond encore à une autre question. Le rapport conserve ces distinctions.
Pourquoi ce Décodeur JWT sépare les contrôles
Lire sans conclure trop vite
Le Décodeur JWT peut afficher une signature correspondante et une date expirée simultanément. Un jeton peut être intact mais trop ancien, ou contenir un JSON plausible sans signature fiable. Cette séparation aide à identifier la cause du refus.
Expérimenter dans un brouillon indépendant
Le générateur de tests crée une paire de clés locale temporaire. Il présente d’abord le jeton et la clé publique dans un aperçu. Appliquer remplace les entrées ensemble ; un rétablissement restaure l’entrée et le résultat précédents.
Définir les attentes avant la comparaison
02
Choisir les données de confiance
Sélectionnez RS256 ou ES256 et fournissez un JWK public ou SPKI PUBLIC KEY PEM. Ajoutez l’émetteur ou l’audience attendus si nécessaire. Aucune référence de l’en-tête ne sélectionne la clé.
03
Fixer le moment à reproduire
Une référence vide utilise l’heure de chaque exécution. Une valeur en secondes Unix permet de reproduire un instant. L’action d’heure actuelle ouvre un aperçu ; toute modification bloque l’export du résultat périmé.
Examiner chaque cause possible de rejet
En-tête et claims lisibles
Les deux objets JSON et les informations de signature restent accessibles. L’algorithme déclaré est distinct de votre choix ; ni kid ni une URL ne suffit à établir la confiance.
Comparaison par clé publique
RS256 accepte RSA de 2048–8192 bits ; ES256 utilise P-256. Une signature différente est distinguée d’une clé incorrecte, d’un algorithme non pris en charge et d’une entrée mal formée.
Vérifications de temps reproductibles
exp, nbf et iat sont comparés à la référence avec une tolérance de 0–86400 secondes. Un iat futur échoue selon la politique de cet outil. Les dates absentes restent indiquées comme absentes.
Émetteur et audience attendus
iss est comparé exactement. aud peut être une chaîne ou un tableau contenant l’audience attendue. Sans attente configurée, le contrôle reste non effectué. La signature ne donne aucun droit d’accès.
Formats acceptés et limites de confiance
- Trois segments compacts seulement
- Fournissez le jeton brut sans préfixe Bearer, espaces périphériques ni remplissage. Les JWE à cinq parties ne sont pas déchiffrés. none peut être lu avec une signature vide, mais n’est jamais vérifié.
- Texte et nombres stricts
- En-tête et claims doivent être des objets JSON UTF-8. Doublons, substituts isolés et base64url non canonique sont refusés. Les fractions représentables sont acceptées ; toute conversion altérant silencieusement le nombre échoue.
- Clés de vérification publiques uniquement
- Utilisez un JWK public unique ou un SPKI PUBLIC KEY PEM complet. Les clés privées et symétriques sont refusées. Les propriétés alg, use ou key_ops incompatibles empêchent aussi la vérification.
- Ni récupération distante ni extensions
- jku, x5u, kid, jwk et x5c restent des métadonnées non fiables. Ils ne déclenchent aucune requête ni sélection de clé. Les signatures contenant crit, b64 ou zip ne sont pas vérifiées.
- Taille et précision des dates
- Limites : 100 000 caractères de jeton, 20 000 de clé, 50 000 de claims de test. Le jeton généré doit lui aussi respecter sa limite. Une date hors plage Date est invalide ; UTC affiche les millisecondes et le rapport conserve la fraction.
- Le test ne remplace pas l’authentification
- Le générateur est désactivé au départ et crée ses clés temporaires seulement sur demande explicite. Appliquer ne vérifie pas automatiquement la signature. Révocation, autorisations et règles métier restent à contrôler dans l’application.
Questions sur le Décodeur JWT
Le décodage contrôle-t-il aussi la signature ?
Non, le décodage initial ne contrôle que la lecture. Pour vérifier la signature, choisissez explicitement RS256 ou ES256 et fournissez une clé publique. Les résultats des claims restent distincts de la comparaison cryptographique.
Le jeton quitte-t-il mon navigateur ?
Le traitement des entrées reste en mémoire dans cette page. Les clés distantes ne sont pas récupérées et les brouillons ne sont pas conservés. Copier ou télécharger produit un rapport uniquement à votre demande.
Pourquoi mon JWT est-il considéré comme mal formé ?
Le format attendu comporte exactement trois segments, sans Bearer ni espaces. Un base64url incorrect, un JSON non conforme, des doublons ou des octets UTF-8 invalides provoquent aussi une erreur. Le contenu n’est pas réparé automatiquement.
Comment interpréter exp et iat ?
Ces valeurs sont des secondes Unix : exp indique l’expiration et iat l’émission. Le rapport les affiche en UTC à la milliseconde, avec le nombre original. Le contrôle utilise votre référence et votre tolérance horaire.
Quels algorithmes de signature sont pris en charge ?
La vérification prend en charge RS256 avec RSA de 2048–8192 bits et ES256 avec P-256. Vous devez choisir l’algorithme. Les autres variantes, none et les extensions crit, b64 ou zip ne sont pas vérifiées.
Un résultat vous surprend ?
Reprendre l’inspection
Utilisez le Décodeur JWT avec l’algorithme attendu, une clé publique connue et une référence de temps choisie ; exportez le rapport correspondant aux entrées actuelles.