jwt_tool CLI : Analyser les JWT ou JSON Web Tokens

Les JWT sont devenus incontournables dans les applications web modernes et les API, mais ils sont aussi régulièrement à l’origine de failles de sécurité lorsqu’ils sont mal configurés. Avec jwt_tool, vous allez pouvoir analyser, décoder et tester des JSON Web Tokens directement depuis votre terminal afin de mieux comprendre leur fonctionnement et vérifier leur sécurité.

Dans ce tutoriel, vous apprendrez pas à pas à installer et utiliser jwt_tool, à lire le contenu d’un JWT, à repérer les erreurs fréquentes et à réaliser vos premiers tests dans un cadre légal et pédagogique.

Même si vous débutez en cybersécurité, vous verrez qu’il est possible de comprendre rapidement les bases… sans avoir besoin d’être un hacker.

• Comprendre enfin ce qu’un JWT contient réellement et pourquoi une mauvaise configuration peut mettre une API entière en danger.
• Prendre en main jwt_tool pas à pas pour analyser des tokens, repérer des erreurs fréquentes et adopter de vrais réflexes de sécurité.
• Apprendre à tester ses propres applications web de manière plus professionnelle sans être expert en cybersécurité.

Les JWT sont partout : connexions à une API, applications modernes, tableaux de bord, espaces membres, outils SaaS… Pourtant, derrière ce petit jeton composé de trois morceaux séparés par des points, il peut parfois se cacher une vraie faille de sécurité.

Nous allons donc découvrir jwt_tool, un outil en ligne de commande conçu pour analyser, tester et comprendre les JWT.

L’objectif ici n’est pas de “pirater pour pirater”, mais d’apprendre à auditer proprement vos propres applications ou un environnement pour lequel vous avez une autorisation. OWASP rappelle d’ailleurs que les JWT sont souvent utilisés comme jetons d’authentification, notamment dans les API REST, et qu’une mauvaise implémentation peut compromettre une application.

Qu’est-ce qu’un JWT ?

Un JWT, pour JSON Web Token, est un jeton qui permet de transporter des informations entre deux systèmes. Dans une application web, il est souvent utilisé après une connexion.

Par exemple, lorsqu’un utilisateur se connecte, le serveur peut lui donner un JWT. Ensuite, à chaque requête vers l’API, le navigateur ou l’application mobile renvoie ce jeton pour prouver son identité.

Un JWT ressemble à ceci :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiAlbanIiwicm9sZSI6InVzZXIiLCJleHAiOjE3MzAwMDAwMDB9.signature

À première vue, on dirait une soupe de lettres. En réalité, il contient trois parties :

HEADER.PAYLOAD.SIGNATURE

Le Header

Le Header indique généralement le type de token et l’algorithme utilisé pour la signature :

{
  "alg": "HS256",
  "typ": "JWT"
}

Ici, alg signifie que le token est signé avec l’algorithme HS256.

Le Payload

Le Payload contient les informations transportées par le JWT. On appelle ces informations des claims :

{
  "user": "Alban",
  "role": "user",
  "exp": 1730000000
}

Ce bloc peut contenir un identifiant utilisateur, un rôle, une date d’expiration ou d’autres données utiles.

Attention cependant : le Payload est simplement encodé, pas chiffré. Cela veut dire qu’on peut le lire facilement. Il ne faut donc jamais y mettre de mot de passe, de clé API ou d’information sensible.

La Signature

La Signature sert à vérifier que le token n’a pas été modifié. Si quelqu’un change le rôle user en admin, la signature ne correspondra plus, sauf si l’attaquant connaît la clé secrète utilisée pour signer le JWT.

C’est justement ce genre de problème que jwt_tool permet de tester.

À quoi sert jwt_tool ?

• jwt_tool est un outil Python en ligne de commande (CLI) dédié à l’analyse des JWT.

Il permet de décoder un token, d’observer son contenu, de tester certaines mauvaises configurations et de mieux comprendre comment une application vérifie ses jetons.

Concrètement, jwt_tool peut servir à :

• analyser la structure d’un JWT ;
• repérer des informations sensibles dans le Payload ;
• vérifier l’algorithme utilisé ;
• tester des faiblesses connues ;
• simuler des modifications de token ;
• vérifier si une clé secrète faible peut être retrouvée.

L’outil est surtout utilisé dans un contexte d’audit de sécurité, de pentest légal ou de formation. Il est très pratique pour comprendre ce qui se passe derrière une authentification par token.

Ce qu’il faut savoir avant de commencer

Avant d’utiliser jwt_tool, retenez une règle simple : vous ne devez tester que vos propres applications, vos environnements de formation ou des systèmes pour lesquels vous avez une autorisation claire.

Tester des JWT sur un site qui ne vous appartient pas peut être illégal. Même si vous êtes “juste curieux”. En cybersécurité, la curiosité est une qualité, mais elle doit rester dans un cadre propre.

Pour pratiquer sans risque, vous pouvez utiliser :

• une API locale
• un laboratoire volontairement vulnérable
• une application de test
• un projet personnel
• une plateforme d’entraînement légale

👉 Apprenez à coder un JWT en PHP.

Installer jwt_tool

jwt_tool fonctionne avec Python. Vous pouvez donc l’utiliser sur Linux, macOS ou Windows, à condition d’avoir Python et Git installés.

Vérifier Python

Dans votre terminal, tapez :

python3 --version

Cette commande affiche la version de Python installée :

Python 3.12.2

Si Python n’est pas installé, vous devrez l’ajouter avant de continuer.

Cloner jwt_tool depuis GitHub

Placez-vous dans un dossier de travail, puis lancez :

git clone https://github.com/ticarpi/jwt_tool.git

Cette commande télécharge le projet jwt_tool sur votre ordinateur.

Ensuite, entrez dans le dossier :

cd jwt_tool

Installer les dépendances

La documentation du wiki jwt_tool indique notamment l’installation de dépendances Python comme termcolor, cprint, pycryptodomex et requests.

Vous pouvez les installer avec :

python3 -m pip install termcolor cprint pycryptodomex requests

Chaque dépendance ajoute une fonctionnalité utile à l’outil : affichage coloré, requêtes HTTP, cryptographie, etc.

Lancer jwt_tool une première fois

Pour vérifier que tout fonctionne :

python3 jwt_tool.py

Lors du premier lancement, l’outil peut créer des fichiers de configuration et des fichiers utiles à son fonctionnement. C’est normal.

Pour afficher l’aide :

python3 jwt_tool.py -h

L’aide liste les options disponibles. Ne cherchez pas à tout retenir dès maintenant. Comme souvent en ligne de commande, on apprend en pratiquant.

Décoder un JWT avec jwt_tool

Prenons un exemple simple. Imaginons que vous ayez ce token de test :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWxiYW4iLCJyb2xlIjoidXNlciJ9.invalidsignature

Pour l’analyser avec jwt_tool :

python3 jwt_tool.py "VOTRE_TOKEN_ICI"

Dans un vrai cas, vous remplacez VOTRE_TOKEN_ICI par le JWT complet.

Exemple :

python3 jwt_tool.py "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWxiYW4iLCJyb2xlIjoidXNlciJ9.invalidsignature"

jwt_tool va afficher les différentes parties du token. Vous pourrez lire le Header, le Payload et observer les informations présentes.

C’est souvent la première étape d’un audit : regarder ce que le token contient.

Comprendre ce que jwt_tool affiche

Lorsque jwt_tool décode un JWT, il vous aide à repérer les éléments importants.

L’algorithme

Dans le Header, vous pouvez voir quelque chose comme :

{
  "alg": "HS256",
  "typ": "JWT"
}

L’algorithme est essentiel. Une mauvaise configuration à ce niveau peut ouvrir la porte à des attaques.

OWASP recommande notamment de ne pas accepter les JWT non sécurisés utilisant alg: none.

Les claims

Dans le Payload, vous trouverez parfois :

{
  "sub": "123",
  "role": "user",
  "iat": 1710000000,
  "exp": 1710003600
}

Quelques champs courants :

• sub représente souvent l’identifiant du sujet, donc l’utilisateur.
• iat signifie issued at, c’est-à-dire la date de création du token.
• exp indique la date d’expiration.
• role peut indiquer le rôle de l’utilisateur.

Ces informations sont très utiles, mais elles doivent être traitées avec prudence. Le serveur ne doit pas faire confiance aveuglément au contenu d’un JWT sans vérifier sa signature.

Tester une mauvaise configuration JWT

Imaginons une application qui donne un JWT à un utilisateur classique :

{
  "user": "alban",
  "role": "user"
}

Un attaquant pourrait être tenté de modifier le rôle :

{
  "user": "alban",
  "role": "admin"
}

Mais si la signature est correctement vérifiée côté serveur, cette modification sera rejetée.

• jwt_tool permet justement de simuler ce genre de modification afin de vérifier si l’application réagit correctement.

L’idée n’est pas de tricher, mais de poser une question simple :

“Si quelqu’un modifie ce token, est-ce que mon application le bloque bien ?”

• Si la réponse est oui, c’est bon signe.
• Si la réponse est non… ça craint.

Tester une clé secrète faible

Avec certains JWT signés en HS256, la sécurité repose sur une clé secrète. Si cette clé est faible, par exemple secret, password ou 123456, elle peut être devinée.

jwt_tool peut tester un token avec une wordlist, c’est-à-dire une liste de mots de passe possibles. (SecList, Rockyou.txt ou créer sa propre wordlist) :

python3 jwt_tool.py "VOTRE_TOKEN" -C -d wordlist.txt

Explication :

-C

Cette option sert à lancer un test de clé faible.

-d wordlist.txt

Cette option indique le fichier contenant les mots à tester.

Le fichier wordlist.txt pourrait contenir :

secret
password
admin
jwtsecret
monmotdepasse

Si la clé utilisée pour signer le JWT est dans cette liste, l’outil peut la retrouver.

C’est pour cette raison qu’il faut toujours utiliser des secrets longs, aléatoires et impossibles à deviner.

Créer une petite wordlist de test

Pour un environnement local, vous pouvez créer un petit fichier :

nano wordlist.txt

Ajoutez quelques lignes :

secret
test
password
creablog
supersecret

Puis enregistrez.

Ensuite, lancez le test :

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

python3 jwt_tool.py "VOTRE_TOKEN" -C -d wordlist.txt

Si jwt_tool trouve la clé, cela signifie que votre secret est beaucoup trop faible.

Dans un vrai projet, vous ne devez jamais utiliser une clé évidente. Une bonne clé ressemble plutôt à une longue chaîne aléatoire.

👉 Tout savoir sur la commande Nano depuis le terminal.

Exemple de bonne clé secrète

Voici un mauvais secret :

secret

Voici déjà mieux :

c9F8!zP2@LmQ7#vX4nT6$wA1

Et dans une vraie application, vous devriez stocker cette clé dans une variable d’environnement, pas directement dans votre code.

Exemple dans un fichier .env :

JWT_SECRET="c9F8!zP2@LmQ7#vX4nT6$wA1"

L’avantage est simple : si vous partagez votre code sur GitHub, vous évitez d’exposer votre secret. Enfin… à condition de ne pas envoyer le fichier .env, bien sûr.

Modifier un JWT pour tester la sécurité

jwt_tool peut aussi aider à modifier des éléments du token. L’objectif est de voir si l’application accepte ou refuse le token modifié.

Par exemple, vous pouvez vouloir tester ce scénario :

{
  "role": "user"
}

devient :

{
  "role": "admin"
}

Une application correctement sécurisée doit refuser le JWT modifié si la signature n’est pas valide.

Ce test est très intéressant pour les développeurs. Il permet de vérifier que l’API ne se contente pas de lire le Payload, mais qu’elle vérifie réellement la signature.

Car oui, une erreur classique consiste à décoder le token et à croire ce qu’il contient sans validation. C’est un peu comme laisser quelqu’un entrer dans un bâtiment parce qu’il a écrit “je suis le patron” sur un Post-it.

Utiliser jwt_tool avec une requête HTTP

Dans un audit plus complet, vous pouvez récupérer un JWT dans une requête HTTP.

Par exemple, une API peut attendre un token dans l’en-tête Authorization :

Authorization: Bearer VOTRE_TOKEN

Avec un outil comme Burp Suite, OWASP ZAP ou les outils développeur du navigateur, vous pouvez observer les requêtes envoyées à l’API.

Ensuite, vous copiez le JWT et vous l’analysez avec jwt_tool.

Le workflow ressemble à ceci :

Connexion à l’application

1. → récupération du JWT
2. → analyse avec jwt_tool
3. → modification contrôlée du token
4. → test sur l’API
5. → vérification de la réponse serveur

• Si l’API refuse le token modifié, c’est bon signe.
• Si elle l’accepte, il y a probablement un problème de validation côté serveur.

Les vulnérabilités JWT fréquentes

Le cas alg:none

Un JWT peut indiquer dans son Header l’algorithme utilisé. Historiquement, certaines mauvaises implémentations acceptaient none, c’est-à-dire aucun algorithme de signature :

{
  "alg": "none",
  "typ": "JWT"
}

Si une application accepte ce type de token, elle peut permettre à quelqu’un de fabriquer un JWT sans signature valide.

Aujourd’hui, les bibliothèques modernes sont généralement mieux protégées, mais ce test reste important en audit.

Les secrets trop simples

Un secret comme celui-ci est dangereux :

secret

Même chose pour :

admin
password
azerty
jwt

Ces valeurs sont trop faciles à deviner. Si votre JWT utilise HS256, choisissez un secret robuste.

Les tokens sans expiration

Un JWT sans expiration peut rester valide indéfiniment. C’est pratique… jusqu’au jour où il fuite.

Ajoutez toujours un claim exp :

{
  "sub": "123",
  "role": "user",
  "exp": 1730000000
}

Un token doit avoir une durée de vie adaptée. Pour un access token, on privilégie souvent une durée courte.

Les données sensibles dans le Payload

Le Payload est lisible. Donc ceci est une très mauvaise idée :

{
  "email": "user@example.com",
  "password": "monmotdepasse"
}

Même si le JWT semble illisible au premier regard, il peut être décodé très facilement.

• Un JWT ne doit pas transporter de secrets.

Bonnes pratiques pour sécuriser vos JWT

Pour bien sécuriser vos JWT, commencez par choisir un algorithme adapté et imposez-le côté serveur. Votre application ne doit pas accepter n’importe quel algorithme annoncé dans le Header.

Ensuite, utilisez une clé robuste si vous signez en HS256. Cette clé doit être longue, aléatoire et stockée hors du code source.

Pensez aussi à vérifier les claims importants. OWASP recommande de valider la signature, mais aussi des éléments comme l’expiration, l’émetteur ou l’audience selon le contexte.

Exemple de contrôles utiles :

• La signature est-elle valide ?
• Le token est-il expiré ?
• L’émetteur est-il celui attendu ?
• L’audience correspond-elle à mon application ?
• Le rôle utilisateur est-il cohérent côté serveur ?

Enfin, évitez de considérer le JWT comme une base de données miniature. Il doit rester léger, clair et limité à ce qui est nécessaire.

Erreurs fréquentes avec jwt_tool

La première erreur consiste à croire que décoder un JWT signifie l’avoir piraté. Non. Décoder un JWT permet simplement de lire son contenu. C’est normal, puisque le Header et le Payload sont encodés en Base64URL, pas chiffrés.

La deuxième erreur est de lancer des tests sur des applications qui ne vous appartiennent pas. Même si jwt_tool est facile à utiliser, son usage doit rester encadré.

Troisième erreur : interpréter trop vite les résultats. Si une modification de token ne fonctionne pas, cela ne veut pas dire que l’application est parfaite. Cela veut seulement dire que ce test précis n’a pas fonctionné.

À l’inverse, si un secret faible est trouvé, il faut corriger immédiatement. Là, le signal est clair.

Mini projet : auditer un JWT de test

Pour pratiquer, imaginez une petite API locale qui génère un JWT avec le Payload suivant :

{
  "user": "demo",
  "role": "user",
  "exp": 1730000000
}

Votre mission consiste à vérifier trois choses.

D’abord, vous analysez le token :

python3 jwt_tool.py "VOTRE_TOKEN"

Vous observez le Header et le Payload.

Ensuite, vous testez si la clé secrète est faible :

python3 jwt_tool.py "VOTRE_TOKEN" -C -d wordlist.txt

• Si jwt_tool retrouve la clé, vous remplacez le secret par une valeur plus robuste.

Enfin, vous essayez de modifier le rôle user en admin, puis vous renvoyez le token à votre API locale.

Le résultat attendu est simple : l’API doit refuser le token modifié.

Si elle l’accepte, vous devez revoir la validation de signature côté serveur.

Exemple de correction côté logique serveur

Voici une logique simplifiée en pseudo-code :

Recevoir le JWT

1. → vérifier la signature
2. → vérifier l’expiration
3. → vérifier l’émetteur
4. → lire les claims seulement si tout est valide
5. → autoriser ou refuser l’accès

L’erreur serait de faire ceci :

Recevoir le JWT

1. → décoder le Payload
2. → lire role = admin
3. → donner l’accès

Dans ce mauvais scénario, l’application fait confiance à une donnée non vérifiée.

La bonne approche consiste toujours à valider le token avant d’utiliser son contenu.

Outils complémentaires à jwt_tool

jwt_tool est très pratique, mais il devient encore plus utile avec d’autres outils.

Vous pouvez utiliser JWT.io pour visualiser rapidement un token dans le navigateur. C’est pratique pour apprendre, mais évitez d’y coller des tokens sensibles issus d’un vrai projet.

Vous pouvez utiliser Postman pour tester vos requêtes API avec différents JWT.

Vous pouvez aussi utiliser Burp Suite ou OWASP ZAP pour observer les requêtes, intercepter les tokens et comprendre comment l’application échange avec le serveur.

jwt_tool s’intègre très bien dans cette logique : vous récupérez le token avec un outil, puis vous l’analysez dans le terminal.

---

FAQ : tout comprendre sur jwt_tool et les JWT

---

jwt_tool est un excellent compagnon pour comprendre les JWT et tester leur sécurité de manière concrète. Il vous force à regarder ce qu’il y a vraiment dans un token, à comprendre le rôle de la signature, à repérer les mauvaises configurations et à adopter de meilleurs réflexes de développeur.

Le plus intéressant, finalement, ce n’est pas seulement l’outil. C’est ce qu’il vous apprend : une authentification ne doit jamais reposer sur une confiance aveugle. Un token doit être signé, vérifié, limité dans le temps et utilisé avec rigueur.

Pour progresser, le mieux est de créer une petite API de test, de générer vos propres JWT, puis de les analyser avec jwt_tool. Vous verrez rapidement la différence entre un token simplement lisible, un token modifiable, et un token correctement protégé.

C’est là que la cybersécurité devient vraiment passionnante : quand on ne se contente plus d’appliquer des recettes, mais qu’on comprend enfin pourquoi elles existent.