Décodeur JWT
Décoder et inspecter les JSON Web Tokens
Token JWT
Qu'est-ce qu'un JWT (JSON Web Token) ?
Un JSON Web Token (JWT) est un format de token compact et sûr pour les URL, défini dans la RFC 7519. Il encode un ensemble de claims sous forme d'objet JSON, puis le signe — et éventuellement le chiffre — afin que le destinataire puisse vérifier que les données n'ont pas été altérées. Les JWT sont le standard de facto pour l'authentification sans état dans les REST APIs, les systèmes d'authentification unique et l'autorisation de microservices.
Anatomie d'un JWT : En-tête · Payload · Signature
Tout JWT est composé de trois segments encodés en base64url séparés par des points. L'en-tête et le payload sont du JSON brut — lisibles par n'importe qui — tandis que la signature est une valeur cryptographique qui ne peut être vérifiée qu'avec la bonne clé.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user123",
"name": "Alice",
"role": "admin",
"iat": 1717200000,
"exp": 1717203600
}Pourquoi utiliser un décodeur JWT ?
Les JWT bruts ressemblent à du texte aléatoire. Cet outil affiche instantanément l'en-tête et le payload sous forme de JSON formaté pour inspecter les claims, vérifier les dates d'expiration et auditer les choix d'algorithmes sans écrire une seule ligne de code.
Référence des claims JWT standard
La RFC 7519 définit sept noms de claims enregistrés. Ils ne sont pas obligatoires, mais leur utilisation est fortement recommandée pour l'interopérabilité. Vous pouvez ajouter n'importe quel claim personnalisé au payload.
| Claim | Description | Type |
|---|---|---|
| iss | Émetteur — Identifie qui a émis le token — par ex. l'URL de votre serveur d'authentification ou le nom de l'application. | string |
| sub | Sujet — Identifie le principal concerné par le JWT — généralement un ID utilisateur ou un compte de service. | string |
| aud | Audience — Identifie les destinataires prévus. La partie réceptrice doit vérifier que cela correspond à son identifiant. | string | string[] |
| exp | Temps d'expiration — Horodatage Unix après lequel le token ne doit plus être accepté. Toujours définir cette valeur pour limiter les dégâts en cas de vol. | number |
| nbf | Pas avant — Horodatage Unix avant lequel le token ne doit pas être accepté. Utile pour planifier des tokens à date future. | number |
| iat | Émis à — Horodatage Unix auquel le token a été émis. Utilisé pour calculer l'âge du token. | number |
| jti | JWT ID — Un identifiant unique pour le token. Permet la révocation en stockant et vérifiant les valeurs JTI utilisées côté serveur. | string |
Algorithmes de signature JWT
Le claim d'en-tête alg déclare quel algorithme a signé le token. Le choix affecte la sécurité, les performances et la capacité des services tiers à vérifier les tokens sans la clé privée.
| Algorithme | Famille | Type de clé | Notes |
|---|---|---|---|
| HS256 | HMAC | Symmetric | Le plus courant. Secret partagé — quiconque possède le secret peut signer et vérifier. |
| HS384 | HMAC | Symmetric | Variante HMAC plus robuste ; coût de performance modéré. |
| HS512 | HMAC | Symmetric | Variante HMAC la plus forte. |
| RS256 | RSA | Asymmetric | Algorithme asymétrique le plus utilisé (Google, Auth0, Okta). La clé publique vérifie sans la clé privée. |
| RS384 | RSA | Asymmetric | Variante RS à sécurité renforcée. |
| RS512 | RSA | Asymmetric | Variante RS la plus forte. |
| ES256 | ECDSA | Asymmetric | Courbe elliptique — signatures plus courtes que RSA, populaire sur mobile et IoT. |
| PS256 | RSA-PSS | Asymmetric | RSA-PSS : plus moderne et plus sûr que RS256 basé sur PKCS1v1.5. |
| none | — | — | Aucune signature — dangereusement critique. N'acceptez jamais de tokens avec alg: none en production. |
Considérations de sécurité
Décoder un JWT est toujours sûr. Faire confiance à un JWT sans vérification appropriée de la signature ne l'est pas. Gardez ces règles à l'esprit chaque fois que vous consommez des tokens dans votre application.
- –Décoder et inspecter un JWT dans les outils de développement ou dans cet outil
- –Utiliser exp, iat et nbf pour comprendre la durée de vie du token
- –Journaliser les claims du payload pour le débogage (omettre les PII sensibles)
- –Lire l'en-tête alg pour comprendre comment le token a été signé
- –Faire confiance aux claims du payload sans vérifier la signature côté serveur
- –Accepter des tokens avec alg: none — cela signifie aucune signature du tout
- –Stocker des tokens d'accès dans localStorage dans des applications à haute sécurité (préférer les cookies httpOnly)
- –Définir exp très loin dans le futur pour des tokens portant des permissions sensibles
Cas d'usage courants
Décoder un JWT en code
L'en-tête et le payload sont encodés en base64url — il suffit d'inverser l'encodage. Base64url remplace + par - et / par _, et omet le rembourrage =. Seule la signature nécessite la clé secrète.
function decodeJWT(token) {
const [, payload] = token.split('.')
const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
return JSON.parse(json)
}const [, payload] = token.split('.')
const decoded = JSON.parse(
Buffer.from(payload, 'base64url').toString()
)import base64, json
def decode_jwt(token):
payload = token.split('.')[1]
padding = '=' * (-len(payload) % 4)
return json.loads(base64.urlsafe_b64decode(payload + padding))TOKEN="eyJhbGc..." echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .