Encodeur JWT en ligne : créer et signer des tokens sans rien installer

Chaque développeur apprend ce qu'est un JWT à peu près au même moment : la première fois où il doit implémenter l'authentification et que quelqu'un le suggère. Vous lisez le RFC, regardez la payload décodée en base64, pensez "ah, c'est juste du JSON" — puis passez l'heure suivante perplexe à propos de ce que fait exactement la partie signature et pourquoi.

La confusion est compréhensible. Les JWT sont simples en structure mais subtils dans leurs implications de sécurité. Ce guide se concentre sur le côté pratique : ce que vous devez réellement savoir pour créer et utiliser des JWT pour les tests et le débogage, et comment l'Encodeur JWT de ToolBox Hubs vous permet de le faire sans installer de bibliothèque ni démarrer de serveur.

Ce qu'est réellement un JWT

Un JSON Web Token est composé de trois chaînes encodées en base64url jointes par des points : header.payload.signature.

Le header identifie le type de token et l'algorithme de signature :

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

La payload contient des claims — essentiellement des paires clé-valeur d'informations :

{
  "sub": "user_12345",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1714000000,
  "exp": 1714086400
}

La signature est un hash cryptographique du header et de la payload encodés, créé en utilisant votre clé secrète. C'est ce qui rend le token résistant à la falsification — changez un seul caractère dans la payload, et la signature ne correspond plus.

Voici la chose qui fait trébucher beaucoup de gens : la payload n'est pas chiffrée. Elle est encodée en base64url, ce qui signifie que toute personne possédant le token peut la décoder et la lire immédiatement. La signature prouve que le token n'a pas été falsifié, mais elle ne fait rien pour cacher le contenu. Cela compte beaucoup pour ce que vous décidez d'y mettre.

Les claims que vous utilisez réellement

La spécification JWT définit une poignée de "claims enregistrées" — des noms de champs avec des significations standard que les bibliothèques savent valider automatiquement.

sub (subject) — De qui parle le token. Habituellement un ID utilisateur ou un identifiant de compte. Doit être stable et unique. Erreur courante : mettre une adresse email ici au lieu d'un ID opaque. Les adresses email changent ; les ID opaques non.

iat (issued at) — Timestamp Unix de quand le token a été créé. Utile pour le débogage, et certaines logiques de validation vérifient cela pour rejeter les tokens qui semblent provenir d'un futur lointain (attaques par décalage d'horloge).

exp (expiration) — Timestamp Unix après lequel le token devrait être rejeté. C'est important. Un JWT sans expiration est valide pour toujours, ce qui signifie que s'il fuit, vous n'avez aucun recours sauf de faire tourner le secret entièrement. Pour les sessions courtes, 15-60 minutes est courant. Pour les refresh tokens, des heures à des jours. Définissez toujours ceci.

iss (issuer) — Une chaîne identifiant qui a émis le token. Utile dans les environnements multi-services pour s'assurer que vous validez des tokens de la bonne source. Votre middleware de validation peut vérifier que iss correspond à une valeur attendue et rejeter tout le reste.

aud (audience) — Pour qui le token est destiné. Empêche un token émis pour le Service A d'être utilisé contre le Service B. Souvent un identifiant d'API ou une liste de services qui devraient accepter le token.

Les claims personnalisées sont acceptables et courantes. Si votre app a besoin d'intégrer un role, un plan, un org_id ou tout autre contexte dans le token pour éviter les recherches en base de données à chaque requête, ajoutez-les aussi. Souvenez-vous juste : tout le monde peut les lire.

Quand vous utiliseriez réellement un encodeur JWT en ligne

La réponse honnête est : pas pour la production. Pour la production, votre serveur d'auth gère la signature — votre secret ne quitte jamais l'environnement serveur, et les tokens sont générés programmatiquement dans le cadre d'un flux de connexion.

Là où un encodeur en ligne est vraiment utile :

Tester un middleware d'auth sans serveur d'auth en cours d'exécution. Vous construisez l'endpoint backend qui valide les JWT, et vous voulez le tester manuellement. Vous avez besoin d'un token valide signé avec un secret connu à coller dans Postman ou curl. Un encodeur en ligne vous donne cela en quelques secondes.

Mocker l'auth en développement local. Votre frontend se construit contre une API qui nécessite une authentification, mais le service d'auth n'est pas encore configuré localement. Générez un token avec les bonnes claims et un secret de test, codez-le en dur dans votre environnement de dev, passez à autre chose. Vous ne déployez pas cela ; vous débloquez le développement local.

Déboguer les échecs de validation de token. Un token est rejeté par votre serveur et vous ne savez pas pourquoi. exp est-il dans le passé ? iss est-il faux ? La payload est-elle malformée ? Un encodeur vous laisse créer un token connu comme bon pour comparer, et un décodeur JWT vous laisse inspecter le mauvais. Ensemble, ils forment une boucle de débogage.

Comprendre le comportement JWT pour la première fois. La meilleure façon de comprendre ce qu'une bibliothèque fait avec un JWT est d'en créer un vous-même et d'observer ce qui se passe. Modifiez l'expiration, changez l'algorithme, observez ce qui casse. Un outil en ligne rend cela pratique sans la friction du code.

Comment fonctionne la signature HS256 (sans les maths)

HS256 signifie HMAC-SHA256. HMAC est une construction qui utilise une fonction de hash (SHA-256 dans ce cas) avec une clé secrète pour produire un code d'authentification de message.

Le processus en termes simples : prenez le header encodé, ajoutez un point, ajoutez la payload encodée. Donnez cette chaîne et votre clé secrète à la fonction HMAC-SHA256. Vous obtenez un hash de longueur fixe. Encodez ce hash en base64url et ajoutez-le comme troisième partie du token.

Pourquoi ça marche ? Parce que HMAC est conçu de telle sorte que sans connaître la clé secrète, vous ne pouvez pas produire un hash valide pour un message donné. Si quelqu'un modifie la payload, il ne peut pas recalculer la signature pour qu'elle corresponde — il aurait besoin du secret pour cela. Quand votre serveur valide un JWT, il refait le même calcul HMAC-SHA256 sur le header et la payload qu'il a reçus, compare le résultat à la signature dans le token, et accepte ou rejette en conséquence.

L'encodeur ToolBox Hubs effectue ce calcul en utilisant l'API Web Crypto intégrée du navigateur — les mêmes primitives cryptographiques utilisées par les navigateurs pour TLS. Ce n'est pas fait avec du JavaScript artisanal ou une bibliothèque tierce louche. Cela vaut la peine de le savoir.

Ce que HS256 ne peut pas faire

HS256 utilise une clé symétrique — le même secret qui signe le token le vérifie aussi. Cela signifie que toute personne qui peut vérifier vos tokens peut aussi les créer. Dans un système où un serveur émet des tokens et un autre les vérifie, les deux serveurs doivent connaître le secret. Partager des secrets entre services est un problème de coordination et de surface de sécurité.

RS256 (et ES256) utilisent des clés asymétriques. Une clé privée signe les tokens — seul le serveur d'auth en a besoin, et elle ne quitte jamais ce serveur. Une clé publique vérifie les tokens — celle-ci peut être distribuée librement, publiée dans un endpoint JWKS, chargée par tout service qui doit vérifier les tokens. Les services peuvent vérifier sans avoir aucune capacité à émettre.

Pour quoi que ce soit de plus complexe qu'un seul service backend, RS256 est généralement le meilleur choix architectural. HS256 est plus simple à mettre en place et convient pour les systèmes plus petits ou les scénarios où vous contrôlez tous les validateurs.

Les choses de sécurité qui méritent d'être répétées

Ne mettez pas de données sensibles dans les JWT. Hashs de mots de passe, numéros de carte de crédit, PII qui n'a pas besoin d'y être — rien de tout cela. La payload est visible pour quiconque détient le token. Cela inclut le client, tout système de logging qui capture les headers d'auth, et tout proxy ou CDN entre les deux. Traitez la payload JWT comme vous traiteriez une chaîne de requête URL : supposez qu'elle est visible.

Utilisez des secrets de test avec les outils en ligne. Même quand un outil est vraiment côté client et n'envoie pas vos données ailleurs, l'habitude de taper des secrets de production dans des UI de navigateur est mauvaise. Créez un secret de test. Utilisez test-secret-do-not-use-in-production comme clé si vous voulez. Traitez le vrai secret comme un mot de passe : il ne quitte pas le serveur où il vit.

Définissez toujours une expiration. Un JWT sans exp est un identifiant éternel. S'il fuit, vous avez un problème jusqu'à ce que vous fassiez tourner la clé de signature — ce qui invalide tous les tokens existants et déconnecte tout le monde. Les tokens à courte durée de vie plus un flux de refresh token est le pattern standard pour une raison.

Les attaques de confusion d'algorithme sont réelles. Certaines bibliothèques JWT ont eu des vulnérabilités historiques où vous pouviez changer le header alg à none et la bibliothèque acceptait des tokens non signés. Validez toujours l'algorithme que votre serveur attend et rejetez tout le reste. Ne faites pas confiance au header alg venant du token lui-même.

ToolBox Hubs vs. jwt.io

jwt.io est l'outil JWT canonique et la plupart des développeurs le connaissent. C'est bien. Mais il y a deux raisons pour lesquelles vous pourriez préférer ToolBox Hubs :

Premièrement, ToolBox Hubs est explicitement axé sur la confidentialité et uniquement côté client. jwt.io a historiquement reçu un examen minutieux quant à savoir si les secrets tapés pourraient être loggés. Je ne dis pas que jwt.io est malveillant — mais quand le modèle de confidentialité d'un outil n'est pas clairement documenté, le calcul des risques change. Notre outil traite tout dans votre navigateur.

Deuxièmement, ToolBox Hubs s'intègre avec des outils associés. Après avoir encodé un JWT, vous pouvez sauter directement au décodeur JWT pour l'inspecter, faire passer la payload par le générateur de hash si vous devez hasher des valeurs, ou utiliser Chiffrement/Déchiffrement de texte si vous avez besoin de chiffrement symétrique pour quelque chose que la payload JWT ne devrait pas porter en clair.

Cela dit : jwt.io a des fonctionnalités que nous n'avons pas, y compris la sélection de bibliothèque et le support RS256 avec génération de paire de clés. Utilisez le bon outil pour ce dont vous avez besoin.

Un workflow pratique pour le dev local

Voici comment j'utilise réellement un encodeur JWT pendant le développement :

1. Décidez quelles claims le token a besoin — généralement sub, exp, et toutes les claims spécifiques à l'app que votre middleware vérifie (comme role ou org_id).

2. Définissez exp à quelque chose suffisamment loin dans le futur pour qu'il n'expire pas pendant une session de débogage. Je fais généralement le temps Unix actuel plus 86400 (24 heures). Le convertisseur de timestamp aide pour le calcul mental.

3. Tapez un secret de test mémorable — quelque chose d'évidemment faux comme dev-secret-not-real.

4. Générez le token et collez-le dans votre client API (Postman, curl, HTTPie, peu importe).

5. Quand quelque chose ne va pas avec la validation, collez le token dans le décodeur JWT pour confirmer que la payload a l'air correcte, puis vérifiez que le secret et l'algorithme attendus de votre serveur correspondent à ceux que vous avez utilisés pour le générer.

Cette boucle résout 90 % de la confusion de débogage liée aux JWT. Les 10 % restants sont généralement le décalage d'horloge (votre exp est décalé) ou un mismatch d'algorithme (vous avez généré HS256, votre bibliothèque attend RS256).

Ce que l'outil ne fera pas

Pour être honnête sur les limitations :

Pas de support RS256 ou ES256. La signature à clé asymétrique n'est pas disponible — vous auriez besoin de fournir une clé privée, et la gérer dans une UI de navigateur ajoute de la complexité. Pour les tests RS256, le package npm jsonwebtoken local ou la bibliothèque python-jose sont plus appropriés.

Pas de révocation de token. Les JWT sont sans état par conception — une fois émis, ils sont valides jusqu'à expiration (en supposant que la signature valide). Il n'y a pas de révocation intégrée. Si vous avez besoin de la capacité d'invalider des tokens spécifiques avant qu'ils n'expirent, vous avez besoin d'une blocklist de tokens sur votre serveur. L'encodeur ne peut pas aider avec ça ; c'est une préoccupation architecturale.

Pas de génération JWKS. Pour les systèmes basés sur RS256, vous voudriez aussi un endpoint JWKS (JSON Web Key Set). C'est hors du scope de cet outil.

Pour tout ce qui est dans le scope — créer des tokens signés HS256 pour les tests et le débogage, comprendre la structure JWT, mocker l'auth en dev local — l'Encodeur JWT fait le travail sans cérémonie.

Pour commencer

Ouvrez l'outil Encodeur JWT, tapez une simple payload comme {"sub": "test-user", "role": "admin"}, définissez un secret de test, et appuyez sur Generate. Regardez la sortie. Puis collez-la dans le décodeur JWT et regardez-la se décomposer.

Une fois que vous avez fait ça une fois, la structure JWT cesse d'être abstraite. Vous savez ce que sont les trois parties, vous savez à quoi ressemble du JSON encodé en base64url, et vous savez que la signature n'est qu'un hash. Tout le reste — intégration de bibliothèque, sélection d'algorithme, validation de claims — se construit sur cette fondation.

Outils associés qui valent la peine d'avoir ouverts à côté de celui-ci : Décodeur JWT pour inspecter les tokens, Générateur de hash pour comprendre ce que produit HMAC, et Chiffrement/Déchiffrement de texte pour les cas où le texte clair encodé en base64 n'est vraiment pas suffisant.