Vérificateur de signature JWT (RS256/ES256, vérification par clé publique)

Un outil pour développeurs qui vérifie les JWT (JSON Web Tokens) signés en RS256 ou ES256 à l'aide d'une clé publique au format PEM (SPKI), directement dans le navigateur. Il décode aussi le header/payload et vérifie la date d'expiration. Rien de ce que vous saisissez n'est envoyé à un serveur ; tout est traité côté navigateur.

Algorithmes de signature pris en charge

Algorithme Type de clé Fonction de hachage Description
RS256 RSA (RSASSA-PKCS1-v1_5) SHA-256 Signature utilisant la cryptographie à clé publique RSA. L'algorithme par défaut pour les jetons d'identité émis par les grands fournisseurs OAuth 2.0/OpenID Connect comme Google, Auth0 et Okta.
ES256 ECDSA (courbe P-256) SHA-256 Signature utilisant la cryptographie sur courbes elliptiques, offrant une sécurité équivalente à RSA avec des clés et signatures plus courtes — de plus en plus utilisée pour les applications mobiles et les objets connectés.

Astuces

  • La clé publique doit être au format PEM (SPKI, commençant par « -----BEGIN PUBLIC KEY----- »). Coller directement un fichier de clé privée ou un certificat (.crt) ne fonctionnera pas.
  • L'algorithme de vérification est choisi automatiquement selon le champ alg du header du JWT (RS256 ou ES256) ; aucune sélection manuelle n'est nécessaire.
  • En même temps que la signature, la revendication exp du payload est également vérifiée, avec un avertissement si le jeton a expiré. Une signature valide ne signifie pas que le jeton doit encore être accepté.
  • Cet outil ne prend en charge que RS256 et ES256. Pour vérifier un JWT signé en HS256, utilisez l'outil complémentaire Encodeur JWT pour le re-signer avec le même secret partagé et comparer le résultat.
  • La clé publique utilisée pour la vérification n'est pas secrète ; vous pouvez donc coller sans risque celle obtenue depuis le point de terminaison public d'un fournisseur d'identité (comme un JWKS).

Questions fréquentes

Non, seuls RS256 et ES256 sont pris en charge. HS256, HS384 et HS512 reposent sur un secret partagé plutôt que sur une clé publique et ne peuvent donc pas être vérifiés par un outil qui n'accepte qu'une clé publique. Pour vérifier une signature HS256, utilisez l'outil complémentaire Encodeur JWT afin de re-signer avec le même secret et comparer le résultat.

Les fournisseurs d'identité (Google, Auth0, Okta, etc.) publient leurs clés publiques via un point de terminaison public appelé JWKS (JSON Web Key Set). Utilisez un outil de conversion JWKS vers PEM, ou consultez la clé publique documentée par le service concerné.

Les causes les plus courantes sont : (1) la clé publique saisie ne correspond pas à la clé privée ayant signé le JWT, (2) le header, le payload ou la signature ont été altérés ou corrompus en cours de transmission, ou (3) des caractères ont été perdus lors de la copie. Essayez de recopier à la fois la chaîne JWT et la clé publique directement depuis la source d'origine.

Actuellement, seuls RS256 et ES256 sont pris en charge. Les variantes utilisant des fonctions de hachage plus longues, comme RS384/RS512 et ES384/ES512, sont des candidates pour une prise en charge future.

Oui — la validité de la signature et l'expiration de exp sont vérifiées et affichées indépendamment. Un jeton avec une signature valide mais un exp expiré devrait généralement encore être rejeté dans des systèmes réels ; pensez donc à bien vérifier aussi l'avertissement d'expiration affiché à l'écran.
ツールくん

Anecdote — HMAC contre signatures à clé publique : quelle différence ?

Les schémas de signature JWT se répartissent en deux grandes familles : à secret partagé (HMAC, par exemple HS256) et à clé publique (RSA/ECDSA, par exemple RS256 et ES256). Avec un secret partagé, le signataire et le vérificateur doivent tous deux détenir la même chaîne secrète ; avec la cryptographie à clé publique, seul le signataire détient une clé privée, tandis que n'importe qui peut vérifier avec la clé disponible publiquement. Cette distinction façonne la conception des API. L'outil complémentaire Encodeur JWT (HS256) convient lorsqu'un même serveur émet et vérifie les jetons, tandis que RS256/ES256 — au cœur de cet outil — conviennent lorsque l'émetteur et le vérificateur appartiennent à des organisations ou des serveurs totalement distincts.

En pratique, les jetons d'identité émis par les grands fournisseurs d'identité tels que Google OAuth 2.0, OpenID Connect, Auth0 et Okta sont presque toujours signés en RS256 (ES256 étant souvent disponible en alternative). Cela permet au fournisseur d'identité d'être le seul à détenir la clé privée, tandis qu'un nombre illimité d'applications clientes peuvent vérifier les jetons avec la seule clé publique — évitant de distribuer un secret à chaque client et confinant le risque de fuite de clé à un seul point, celui du signataire.

RS256 et ES256 utilisent tous deux SHA-256 pour le hachage, mais diffèrent par la cryptographie sous-jacente. RS256 utilise RSA (généralement des clés de 2048 bits ou plus), ce qui tend à produire des signatures plus grandes, mais bénéficie de bibliothèques matures et largement prises en charge. ES256 utilise la cryptographie sur courbes elliptiques (P-256), atteignant une sécurité comparable avec des clés et signatures bien plus courtes — un choix de plus en plus prisé pour les environnements mobiles et les API où la taille du payload compte.

→ Voir toutes les anecdotes