Vérificateur de signature JWT
Vérifiez localement la signature d’un JWT avec un secret ou une clé publique, ainsi que l’émetteur, l’audience et les dates si nécessaire.
Vérificateur de signature JWTCollez un JWT compact signé composé exactement de trois parties séparées par des points.Saisissez le secret HMAC, la clé publique SPKI PEM ou la JWK publique correspondante.Indiquez facultativement l’émetteur, l’audience et la tolérance d’horloge attendus.Vérifiez puis examinez l’algorithme, le format de clé, le Header et les Claims sans les assimiler à une autorisation.
Démarrage rapide
1
2
3
4
Scénarios courants
Débogage d’API
contrôlez si un token et une clé connue donnent une signature valide.
Migration
confirmez les tokens pendant un changement de clé HS, RS, PS ou ES.
Correspondance
vérifiez qu’une clé publique correspond à un token signé.
Claims
comparez iss, aud, exp et nbf aux valeurs attendues par votre intégration.
Conseils d'utilisation
Obtenez les clés par un canal de confiance et confirmez l’émetteur et l’audience attendus par votre backend.
Traitez les secrets HMAC et tokens comme sensibles ; effacez-les après usage, surtout sur un appareil partagé.
Réservez ce contrôle au diagnostic. Le backend doit appliquer autorisation, révocation, session et règles métier.
Contrat de vérification
L’entrée doit être un JWT JWS compact en trois parties : header.payload.signature. Les JWE à cinq parties et formats imbriqués ou personnalisés sont exclus.
Famille de clé et algorithme attendu sont choisis séparément. header.alg ne modifie aucun choix ; les trois doivent correspondre. HS utilise UTF-8 ou Base64URL, RS/PS/ES une clé SPKI PEM ou JWK publique.
L’outil vérifie la signature, applique exp et nbf, et ne contrôle iss ou aud que si vous fournissez une valeur attendue. La tolérance concerne le temps.
Périmètre de sécurité
Une signature valide indique que les octets correspondent à la clé fournie et à l’algorithme déclaré ; elle n’établit ni la provenance de la clé ni la fiabilité de l’émetteur.
Le résultat ne contrôle pas scopes, rôles, droits, révocation, déconnexion, session, nonce, azp, subject ou règles métier, et n’accorde aucun accès.
Confirmez séparément clé, émetteur, audience et politique d’algorithmes. Une paire token-clé erronée mais cohérente peut aussi être validée ici.
Non pris en charge : JWE, émission ou signature, clés privées, certificats X.509, EdDSA, JWK sets/JWKS, découverte OIDC, chargement distant et introspection serveur.
Limitations et compatibilité
Seuls les JWT JWS compacts signés en trois parties sont acceptés ; pas les JWE chiffrés en cinq parties.
Seuls HS, RS, PS et ES pris en charge peuvent être vérifiés ; alg none et EdDSA sont refusés.
La clé publique doit être un bloc SPKI PUBLIC KEY PEM ou une JWK publique unique, jamais une clé privée, un certificat, un JWKS ou une URL.
Aucune requête réseau, découverte OIDC, actualisation JWKS, révocation, émission, signature, téléchargement ou partage de résultat.
Confidentialité & sécurité
L’analyse et la vérification s’effectuent localement dans le navigateur. Tokens, secrets, PEM/JWK, émetteur, audience et résultats ne sont ni envoyés ni stockés dans l’URL, Workspace ou WebDAV. Si la synchronisation WebDAV est activée, seules quatre préférences non sensibles peuvent être synchronisées : algorithme attendu, type de clé, encodage du secret et tolérance d’horloge.
Utilisez un appareil privé, effacez les champs après usage et évitez les extensions douteuses ou le partage d’écran.
FAQ
Elle peut exiger un autre émetteur ou une autre audience, refuser l’algorithme ou appliquer scopes, rôles, révocation, sessions, nonce, azp et d’autres règles inconnues de cet outil.
Non. Il n’effectue aucune requête réseau et accepte seulement un SPKI PUBLIC KEY PEM ou une JWK publique pour RS/PS/ES. JWKS, OIDC, X.509 et sélection distante sont exclus.