Outils JWT pour les développeurs Décoder, Encoder et Vérifier l'Expiration du Token

Chaque développeur backend a dû faire face à cette situation : un code 401 Unauthorized apparaît dans la console, et le défi commence. Le token est-il expiré ? A-t-il été signé avec le mauvais secret ? Le payload a-t-il perdu une déclaration entre les services ? Les JWT — JSON Web Tokens — sont le tissu de connexion de l'authentification moderne, et lorsqu'ils se brisent, tout derrière la porte d'authentification devient sombre.

Le problème n'est pas que les JWT sont complexes. La structure est en réalité simple : trois segments encodés en base64url séparés par des points — en-tête, payload, signature. Le problème est que, sans décoder, un token brut comme eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc0NjA5NjAwMH0.mK2xVpQ8nZ3aF7tLdRhW6sYbcXeUoIPjNvGqTmAS1kE ne vous dit rien. Et décoder ce token — rapidement, dans un navigateur, sans installer de logiciel — est exactement ce que ces trois outils libres permettent de faire.

Ce guide décrit l'ensemble du flux JWT : décoder un token pour inspecter son contenu, encoder un token pour simuler l'authentification dans les tests, et vérifier l'expiration pour diagnostiquer les erreurs de timeout. Chaque section utilise le même token fictif ci-dessus afin que vous puissiez suivre le processus de bout en bout.

Outil 1 — Décrypteur JWT : Voir l'intérieur de tout token instantanément

Le décodeur JWT prend n'importe quel token et le découpe en ses trois composants, décode l'en-tête et le payload de base64url en JSON lisible.

Collez le token d'exemple ci-dessus et vous verrez l'en-tête décodé à :

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

Et le payload :

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1746096000
}

Cela exp est un timestamp Unix. À première vue, cela signifie rien — mais le décodeur le convertit en date lisible, afin que vous sachiez immédiatement si le token est encore valide ou déjà périmé.

Une chose à comprendre : le décodeur ne vérifie pas la signature par défaut. La vérification de la signature nécessite le secret (pour HS256) ou la clé publique (pour RS256/ES256). Ce que le décodeur vous fournit est le contenu décodé — ce qui est tout ce dont vous avez besoin lors de la débogage d'une erreur 401, de vérification des déclarations incluses ou d'inspection d'un token provenant d'un fournisseur d'identité tiers.

À noter : le payload du JWT est encodé en base64url, pas chiffré. Tout outil (ou personne) possédant le token peut lire le payload sans le secret. La signature prouve seulement que le token n'a pas été altéré. C'est pourquoi vous ne devez jamais stocker des données sensibles — mots de passe, numéros de carte bancaire, numéros d'assurance — dans le payload d'un JWT.

Outil 2 — Encodeur JWT : Créer des tokens pour les tests

Le Encodeur JWT fait l'inverse : vous fournissez un payload JSON, choisissez un algorithme (HS256 est par défaut), entrez un secret, et l'outil génère un token signé que vous pouvez utiliser immédiatement.

L'usage le plus courant est de simuler l'authentification dans les tests. Supposons que vos tests d'intégration aient besoin d'atteindre une API protégée. Au lieu de configurer un flux de connexion réel, vous construisez un token avec les déclarations exactes attendues par l'endpoint :

{
  "sub": "test_user_001",
  "role": "editor",
  "iat": 1746009600,
  "exp": 1746096000
}

Signez-le avec votre secret de test, collez le résultat dans les en-têtes de votre test, et vos routes protégées répondent comme si un utilisateur réel était authentifié. Aucun mocking du middleware d'authentification, aucune mise en place d'un fournisseur d'identité — juste un token valide avec les déclarations nécessaires.

L'encodeur est également utile lorsque vous développez une nouvelle fonctionnalité et souhaitez tester manuellement la manière dont elle gère des combinaisons spécifiques de déclarations : rôles manquants, tokens périmés, portées inattendues. Gérez des tokens avec des payloads d'exception et les lancez sur votre middleware pour voir comment il réagit.

Si vous devez comprendre l'étape d'encodage en base64url — puisque le payload du JWT est simplement encodé, pas chiffré — l' décodeur base64 vous permet de décoder manuellement n'importe quel segment. Collez la partie centrale de n'importe quel token (le segment payload) dans le décodeur base64 et vous obtenez le JSON brut. Même approche, étape par étape.

Outil 3 — Vérificateur d'expiration JWT : Diagnostiquer les 401 sans faire de calculs

L'expiration du token est responsable d'une grande part des échecs d'authentification en production. Le vérificateur d’expiration JWT prend n'importe quel token et vous indique immédiatement : est-il périmé ? Si oui, depuis combien de temps ?

Collez le token d'exemple et le vérificateur extrait le exp champ, le convertit à partir d'un timestamp Unix en date lisible, et le compare au moment actuel. Vous obtenez un statut clair : valide (avec le temps restant) ou périmé (avec le temps écoulé).

Cela importe davantage qu'il ne le semble. Lorsqu'un 401 apparaît en production, la première question est toujours : « est le token périmé ou y a-t-il un autre problème ? » Répondre à cette question par des calculs mentaux sur un timestamp Unix — 1746096000 - current_time / 3600 — occupe du temps et introduit des erreurs. Le vérificateur d'expiration répond à cette question en une seule collée.

Il affiche également le iat (timestamp d'émission) lorsque présent, afin que vous puissiez voir exactement quand le token a été généré et combien de temps la session est active. Utile pour diagnostiquer des bugs de rafraîchissement de token ou pour identifier pourquoi une session longue a soudainement échoué.

Assemblage : Un flux typique de débogage

Vous recevez un 401. Voici la voie la plus rapide de l'erreur à la résolution :

1. Vérifiez d'abord l'expiration. Collez le token dans le 2. Confusion sur l’algorithme. Si le token est périmé, la solution est un rafraîchissement du token — aucune autre débogage n'est nécessaire.
2. Inspectez le payload. Si le token est encore valide, collez-le dans le décodeur JWT. Vérifiez les déclarations : est-ce que la sub est correcte ? Est-ce que la role ou scope est présente ? L'audience (aud) est-elle correcte pour l'endpoint que vous atteignez ?
3. Reproduisez avec un token personnalisé. Si vous suspectez qu'une combinaison spécifique de déclarations cause le rejet, construisez un token avec l' encodeur et testez directement. Cela isole si c'est le contenu des déclarations ou la structure du token lui-même qui cause l'échec.

Trois outils, moins d'une minute, sans installation. La plupart des erreurs 401 liées aux JWT sont résolues à l'étape 1 ou 2.

Vous aimerez peut-être aussi

Nouveau

Pagination basée sur le curseur versus pagination par décalage — Pourquoi page=2 supprime silencieusement des enregistrements

En savoir plus "

Mis à jour le 15 juin 2026

Nouveau

Builds multistage Docker : Réduisez votre image sans compromettre le déploiement

En savoir plus "

Mis à jour le 14 juin 2026

Nouveau

Flux OAuth 2.0 : Code d'autorisation, PKCE et identifiants du client

En savoir plus "

Mis à jour le 13 juin 2026

Nouveau

HTTP/2 vs HTTP/3 : Qu'est-ce qui a réellement changé (et si votre API s'y intéresse)

En savoir plus "

Mis à jour le 12 juin 2026