Créer un JSON Web Token (JWT) signé

Qu'est-ce que JWT Builder ?

JWT Builder est un outil en ligne qui produit un JSON Web Token signé (JWT) à partir d'un payload JSON et d'un secret HMAC. Il s'adresse aux développeurs qui ont besoin de générer rapidement un token de test pour vérifier le comportement d'une API, simuler une session authentifiée dans Postman, ou reproduire un bug lié à l'expiration ou à la portée d'un token.

Contrairement à notre JWT decoder, qui se contente de lire un token existant, JWT Builder fabrique un token complet : il construit le header, encode le payload, calcule la signature HMAC et assemble le tout au format compact header.payload.signature attendu par toutes les bibliothèques JWT du marché.

Pourquoi générer un JWT ?

Un builder de JWT n'a pas vocation à émettre des tokens de production. C'est avant tout un outil de développement et de tests. Voici les scénarios les plus courants :

• Tests d'intégration : produire des JWT prévisibles pour piloter des tests E2E qui frappent des endpoints protégés sans dépendre du vrai fournisseur d'identité.
• Mocks d'API : remplacer temporairement un appel à l'IdP par un JWT signé localement avec le même secret de test.
• Développement local : se connecter à son propre backend en générant à la main un token contenant les claims voulus, sans avoir à passer par tout le flow OAuth2.
• Démos : illustrer un parcours d'authentification ou un workflow basé sur des permissions sans avoir un IdP réel sous la main.
• Reproduction de bugs : forger un token expiré, un token avec un aud incorrect, un token sans certains claims, pour tester les chemins d'erreur de votre API.
• Debugging d'un parser custom : injecter des JWT spécialement construits pour tester un parser maison.

Composition d'un JWT

Un JWT signé est composé de trois segments séparés par un point, chacun encodé en Base64URL (variante de Base64 sans padding et avec -/_ au lieu de +//) :

• Header : un objet JSON qui décrit l'algorithme de signature et le type du token, par exemple {"alg":"HS256","typ":"JWT"}. JWT Builder le génère automatiquement à partir de l'algorithme que vous choisissez.
• Payload : un objet JSON arbitraire qui contient les claims du token (sujet, permissions, dates d'expiration). C'est la partie que vous fournissez.
• Signature : un HMAC-SHA calculé sur la concaténation base64url(header) + "." + base64url(payload) avec votre clé secrète. C'est elle qui garantit l'intégrité du token.

Cas d'usage en détail

• API mock pour tests E2E : votre suite Cypress ou Playwright doit appeler une API qui exige un Authorization: Bearer .... Plutôt que d'orchestrer un login complet à chaque test, on signe un JWT à la volée avec le secret partagé et on l'injecte dans l'en-tête.
• Démo de SSO : présenter un parcours d'authentification fédérée sans dépendre d'un IdP en ligne.
• Fixture de test : générer un JWT déterministe à partir d'un payload connu pour servir de fixture stable dans des tests unitaires.
• Diagnostic d'un parser custom : tester un parseur JWT maison avec des tokens volontairement minimaux ou volontairement bizarres (claims manquants, types inattendus).
• Apprentissage : comprendre concrètement comment un JWT se construit, en modifiant le payload et en observant la signature changer.

Algorithmes supportés : HS256, HS384, HS512

Notre outil supporte les trois algorithmes HMAC standards de la spécification JWT (RFC 7519) :

• HS256 : HMAC avec SHA-256. Signature de 32 octets. Le plus utilisé en pratique, bon compromis entre rapidité et solidité cryptographique. Recommandé par défaut.
• HS384 : HMAC avec SHA-384. Signature de 48 octets. Adapté aux contextes qui exigent une marge de sécurité supérieure.
• HS512 : HMAC avec SHA-512. Signature de 64 octets. Le plus robuste, au prix d'un token légèrement plus volumineux.

HMAC ou RSA ?

Les algorithmes HS* sont symétriques : la même clé sert à signer et à vérifier. C'est simple et rapide, mais cela signifie que tout service capable de vérifier un token est aussi capable d'en émettre. Si vous avez besoin de séparer ces deux rôles (un seul émetteur, plusieurs consommateurs), tournez-vous vers les algorithmes RS256/RS384/RS512 (RSA, asymétriques), que vous pouvez vérifier avec notre JWT verifier.

Sécurité : protéger votre secret

La sécurité d'un JWT signé en HMAC repose entièrement sur la confidentialité du secret. Quelques règles de base :

• Utilisez un secret long et aléatoire. La RFC 7518 recommande au minimum la taille de la sortie de l'algorithme (32 octets pour HS256, 48 pour HS384, 64 pour HS512). Un mot de passe humain comme azerty123 est trivialement attaquable par force brute hors ligne.
• Ne signez jamais un JWT côté client. Le secret se retrouverait dans le code JavaScript distribué au navigateur, exposé à tout utilisateur. La signature doit toujours rester côté serveur.
• Stockez le secret dans une variable d'environnement (ex. JWT_SECRET), jamais dans un dépôt Git. Pensez à utiliser un coffre comme HashiCorp Vault, AWS Secrets Manager ou les Symfony Secrets selon votre stack.
• Faites tourner le secret régulièrement (key rotation), surtout après tout incident ou départ d'une personne ayant eu accès à la configuration.
• JWT Builder est destiné aux tests et à l'apprentissage. Pour de la production, utilisez la bibliothèque JWT de votre framework (lcobucci/jwt, firebase/php-jwt, jose-php).

Bonnes pratiques de claims

Le payload est un objet JSON libre, mais la RFC 7519 définit un ensemble de registered claims que les bibliothèques JWT savent interpréter. Inclure les bons claims rend votre token portable et évite des bugs subtils :

• iss (issuer) : identifiant de l'émetteur, par exemple "https://api.example.com".
• sub (subject) : identifiant de la personne ou entité concernée, souvent l'ID utilisateur.
• aud (audience) : à qui le token est destiné, pour empêcher la réutilisation d'un token sur une autre API.
• exp (expiration time) : timestamp Unix après lequel le token n'est plus valide. Toujours inclure, même pour un token de test : un token sans expiration est une mauvaise habitude difficile à corriger ensuite.
• nbf (not before) : timestamp avant lequel le token n'est pas encore valide. Utile pour pré-émettre un token activable plus tard.
• iat (issued at) : timestamp d'émission, utile pour journaliser et révoquer.
• jti (JWT ID) : identifiant unique du token, indispensable pour l'idempotence et pour implémenter une liste de révocation.

Exemple de payload typique

{
  "iss": "https://api.example.com",
  "sub": "user-12345",
  "aud": "mobile-app",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "scope": "read:profile write:profile"
}

Comment utiliser l'outil

1. Saisissez le payload sous forme de JSON valide. C'est un objet, donc il commence par { et se termine par }.
2. Indiquez le secret HMAC. Choisissez une chaîne longue et aléatoire pour les tokens de production.
3. Sélectionnez l'algorithme : HS256 par défaut, HS384 ou HS512 selon vos besoins.
4. Cliquez sur créer. Le JWT signé apparaît, prêt à coller dans un en-tête Authorization: Bearer ....
5. Vous pouvez ensuite vérifier le token avec le même secret pour confirmer la cohérence du round-trip, ou le décoder pour relire son contenu.

Questions fréquentes

Exemple de requête

curl -X POST https://cdrn.fr/api/v1/tools/jwt-builder/execute \
  -H "Content-Type: application/json" \
  -d '{"payload":"...","secret":"...","algorithm":"HS256"}'

Schéma d'entrée

Points d'accès

• GET https://cdrn.fr/api/v1/tools - liste tous les outils disponibles
• GET https://cdrn.fr/api/v1/tools/jwt-builder - récupère le schéma de cet outil
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - exécute cet outil avec un payload JSON