Crear un JSON Web Token (JWT) firmado

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é.

Structure 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.

Choisir l'algorithme : 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...).

Claims standard à inclure dans le payload

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. Indispensable.
• nbf (not before) : timestamp avant lequel le token n'est pas encore valide.
• iat (issued at) : timestamp d'émission, utile pour journaliser et révoquer.
• jti (JWT ID) : identifiant unique du token, indispensable si vous voulez 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,
  "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.

Questions fréquentes

Ejemplo de solicitud

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

Esquema de entrada

Puntos de acceso

• GET https://cdrn.fr/api/v1/tools - lista todas las herramientas disponibles
• GET https://cdrn.fr/api/v1/tools/jwt-builder - recupera el esquema de esta herramienta
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - ejecuta esta herramienta con un payload JSON