Verificar a assinatura de um JSON Web Token (JWT)

verifica a assinatura de um JWT (HS256, HS384, HS512, RS256, RS384, RS512) a partir de um segredo ou de uma chave pública, e inspeciona as suas claims
Para HS256 / HS384 / HS512: a cadeia secreta. Para RS256 / RS384 / RS512: a chave pública em formato PEM.

Pourquoi vérifier la signature d'un JWT ?

Un JSON Web Token (JWT) se décompose en trois parties séparées par des points : header.payload.signature. Décoder un JWT consiste simplement à lire les deux premières parties (qui sont du Base64 URL). N'importe qui peut le faire, et n'importe qui peut fabriquer un JWT avec le payload de son choix. Ce qui rend un JWT digne de confiance, c'est uniquement la signature : sans vérification, accepter un JWT revient à laisser entrer chez vous toute personne qui prétend être quelqu'un, sans demander de pièce d'identité.

Cet outil vérifie la signature d'un JWT à partir d'une clé. Il ne se contente pas de décoder : il recalcule la signature à partir du header, du payload et de votre clé, puis la compare avec la signature du token. Si les deux concordent, le token est authentique. Sinon, il a été forgé, modifié, ou signé avec une autre clé.

Algorithmes supportés

Notre outil supporte les deux familles d'algorithmes les plus utilisées pour signer un JWT :

  • HMAC (HS256, HS384, HS512) : signature symétrique. La même clé secrète sert à signer et à vérifier. Simple à mettre en place, mais toute partie qui doit vérifier le token connaît aussi la clé qui permet d'en émettre.
  • RSA (RS256, RS384, RS512) : signature asymétrique. La clé privée signe, la clé publique vérifie. Idéal lorsque l'émetteur et les vérificateurs sont des entités distinctes (OAuth2, OpenID Connect, fédération d'identité).

Comment fonctionne la vérification ?

Notre serveur reproduit exactement l'opération qu'a faite l'émetteur :

  1. Il sépare le JWT en header, payload et signature.
  2. Il concatène base64url(header) + "." + base64url(payload).
  3. Pour HMAC, il calcule un HMAC-SHA-256/384/512 avec votre clé secrète, puis compare avec la signature reçue via hash_equals (comparaison à temps constant pour éviter les attaques temporelles).
  4. Pour RSA, il appelle openssl_verify avec votre clé publique au format PEM.

Cas d'usage

  • Debug d'authentification API : vous recevez un 401, vérifiez si votre token est bien signé avec la clé attendue.
  • Validation d'un token reçu : un partenaire vous envoie un JWT, vous voulez confirmer qu'il vient bien de lui.
  • Audit de sécurité : vérifier qu'un service tiers signe correctement ses tokens avec un algorithme robuste.
  • Tests manuels : vérifier qu'un JWT généré par votre code passe bien la vérification avec la clé publique fournie.

Comment utiliser l'outil

  1. Collez le JWT complet (les trois parties séparées par des points).
  2. Indiquez la clé adaptée à l'algorithme du header :
    • Pour HS256, HS384 ou HS512, la clé est la chaîne secrète partagée avec l'émetteur. C'est une chaîne libre, souvent stockée dans une variable d'environnement comme JWT_SECRET.
    • Pour RS256, RS384 ou RS512, la clé est la clé publique au format PEM, qui commence par -----BEGIN PUBLIC KEY----- et se termine par -----END PUBLIC KEY-----.
  3. Lancez la vérification. L'outil affiche le statut (valide ou invalide) et le payload décodé.

Exemple de clé publique RSA attendue

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxe...
...vQIDAQAB
-----END PUBLIC KEY-----

L'algorithme "none" est rejeté

Le standard JWT autorise un algorithme none, qui signifie "pas de signature". C'est une des sources historiques de failles JWT les plus connues : un attaquant change l'algorithme du header en none, supprime la signature, et le serveur accepte le token. Notre outil rejette systématiquement les tokens avec alg: none. Aucun JWT non signé ne peut passer la vérification.

Claims temporels : exp et nbf

Au-delà de la signature, un JWT valide doit aussi respecter ses contraintes temporelles :

  • exp (expiration) : le token n'est plus valide après cette date.
  • nbf (not before) : le token n'est pas encore valide avant cette date.

Notre outil signale explicitement quand un token est expiré ou pas encore valide, même si sa signature est correcte. C'est important : une signature valide sur un token expiré ne doit jamais être acceptée en production.

Différence avec notre JWT decoder

Notre JWT decoder se contente de décoder les parties header et payload pour les rendre lisibles. Il n'effectue aucune vérification de signature et ne demande pas de clé. Utilisez-le pour inspecter rapidement le contenu d'un token. Utilisez le JWT verifier (cette page) dès que vous avez besoin de prouver qu'un token est authentique.

Questions fréquentes

Que faire si la signature est invalide ?

Vérifiez d'abord l'algorithme : un token signé en HS256 ne se vérifie pas avec une clé RSA, et inversement. Vérifiez ensuite la clé : un caractère blanc en trop, un retour à la ligne manquant dans une clé PEM, ou un secret HMAC légèrement différent de celui utilisé par l'émetteur suffisent à faire échouer la vérification.

Comment générer une paire de clés RSA pour signer mes JWT ?

Avec OpenSSL : openssl genrsa -out private.pem 2048 puis openssl rsa -in private.pem -pubout -out public.pem. La clé privée signe côté émetteur, la clé publique vérifie côté consommateur.

Pourquoi mes tokens sont rejetés alors que le payload semble bon ?

Le payload peut contenir n'importe quoi tant que la signature ne correspond pas à la clé fournie. Une signature valide ne dépend pas du sens du payload : elle dépend uniquement du calcul cryptographique sur le header et le payload exacts.

Quelle différence entre HMAC et RSA pour signer un JWT ?

HMAC est symétrique : un seul secret est partagé entre l'émetteur et le vérificateur, donc tout vérificateur peut aussi émettre des tokens. RSA est asymétrique : seule la clé privée signe, la clé publique se distribue librement. RSA est obligatoire dès que vous voulez exposer un endpoint de vérification public sans donner le pouvoir d'émettre des tokens.

Faut-il chiffrer le JWT en plus de le signer (JWE) ?

Un JWT signé (JWS) garantit l'intégrité et l'authenticité, mais le payload reste lisible par quiconque le récupère. Si le token contient des données sensibles (identifiants internes, droits détaillés, données personnelles), envisagez le format JWE (JSON Web Encryption) qui chiffre le payload en plus de le signer.

Exemplo de pedido

curl -X POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"...","key":"..."}'

Esquema de entrada

Campo Tipo Obrigatório Predefinição
token text
key text

Pontos de acesso

  • GET https://cdrn.fr/api/v1/tools - lista todas as ferramentas disponíveis
  • GET https://cdrn.fr/api/v1/tools/jwt-verifier - obtém o esquema desta ferramenta
  • POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - executa esta ferramenta com um payload JSON