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. |
Vérifier la signature d'un JWT avec une clé publique
Cet outil vérifie un JWT signé en RS256 ou ES256 face à une clé publique au format PEM selon SPKI. Il affiche l'en-tête et la charge utile décodés à côté de l'expiration. Tout ce que vous saisissez est traité dans le navigateur et n'est jamais transmis ailleurs.
**Il convient de souligner qu'une signature valide et un jeton valide sont deux choses distinctes.** Qu'une signature se vérifie ne prouve que ceci : le contenu n'a pas été réécrit depuis son émission. Une authentification véritable exige en outre de contrôler que l'`exp` pour l'expiration, le `nbf` pour l'instant à partir duquel le jeton vaut, l'`iss` pour l'émetteur et l'`aud` pour le destinataire prévu concordent avec ce que vous attendez. **L'autre écueil bien connu en implémentation consiste à laisser l'en-tête du jeton décider lui-même de l'algorithme de vérification.** Si le serveur ne fixe pas à l'avance l'`alg` recevable, il laisse ce choix à portée d'un attaquant.
Comment vérifier
- Collez le JWT C'est une chaîne de trois parties séparées par des points.
- Collez la clé publique au format PEM **C'est bien la clé publique qu'il faut, non la privée.** RS256 prend une clé RSA et ES256 une clé sur la courbe P-256.
- Vérifiez la signature L'outil indique si la clé et la signature concordent.
- Contrôlez le contenu décodé et l'expiration **Un jeton dont la signature se vérifie ne doit pas pour autant servir une fois expiré.** Regardez les deux.
Astuces pour en tirer le meilleur parti
- 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
algdu header du JWT (RS256 ou ES256) ; aucune sélection manuelle n'est nécessaire. - En même temps que la signature, la revendication
expdu 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).
Dans quels cas s'en servir
Pour examiner le contenu d'un jeton d'identité
Un jeton émis par un fournisseur d'identité se confronte à sa clé publique.
Pour démêler une clé erronée d'une signature abîmée
**Lorsque la vérification échoue, vous établissez sur place laquelle des deux est en cause.**
Pour éprouver une rotation de clés
Essayer tour à tour l'ancienne et la nouvelle clé confirme que la relève se déroulera comme prévu.
Pour remonter à la cause d'une panne
Devant un signalement d'échec d'authentification, vous pouvez d'abord établir si le jeton lui-même est en faute.
Vocabulaire de la vérification de JWT
- RS256
- Un procédé de signature employant une clé RSA avec SHA-256. **Signer demande la clé privée, vérifier la clé publique.**
- ES256
- Un procédé de signature employant la courbe P-256 avec SHA-256. Clé comme signature en ressortent plus courtes qu'avec RSA.
- SPKI
- La forme normalisée dans laquelle une clé publique est portée. En PEM, elle s'ouvre par `-----BEGIN PUBLIC KEY-----`.
- Exp
- La revendication qui donne l'expiration. **Si impeccable que soit la signature, un jeton passé cet instant ne doit pas être accepté.**
- Nbf
- La revendication qui indique à partir de quand le jeton devient utilisable. Avant cela, il n'est pas encore en vigueur.
- Confusion d'algorithmes
- **Une faiblesse des implémentations qui vérifient avec l'algorithme désigné par l'en-tête du jeton.** Le procédé accepté doit être fixé du côté qui vérifie.
Questions fréquentes
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.