Générateur de secret JWT gratuit — HS256/384/512

Qu'est-ce qu'un générateur de secret JWT ?

// The secret you generate here goes straight into your signing code.
// Node.js with jsonwebtoken — the JWT_SECRET env var holds the key.
import jwt from 'jsonwebtoken';

const secret = process.env.JWT_SECRET; // e.g. base64url value from this tool

// Sign a token with HS256 (HMAC-SHA-256).
const token = jwt.sign({ sub: 'user-42', role: 'member' }, secret, {
  algorithm: 'HS256',
  expiresIn: '15m'
});

// Verify it — pin the algorithm to a whitelist; never trust the token's alg.
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });

// ---------------------------------------------------------------
// Python with PyJWT — same secret, same algorithm pinning.
// import jwt
// token = jwt.encode({"sub": "user-42"}, key, algorithm="HS256")
// payload = jwt.decode(token, key, algorithms=["HS256"])  # whitelist!

// ---------------------------------------------------------------
// Equivalent-strength CLI generation (32 bytes for HS256):
//   openssl rand -base64 32
//   node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
//   python -c "import secrets; print(secrets.token_urlsafe(32))"

Fonctionnalités clés

Exemples concrets

Algorithme : HS256 · Format : base64url

3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Algorithme : HS512 · Format : base64url

k2Lp9XqA0mNbVcZ7rT4wYsHfGjUe8RoIdPlNkBvM3xQ1aWtCyZuS6FhEgJ (86 chars)

Cliquez sur « Copier pour .env »

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Afficher la commande CLI

openssl rand -base64 32

Basculez l'icône en forme d'œil

•••••••••••••••••••••••••••••••••••••••••••  ↔  3sJ9aFq2kP7m…

Comment utiliser le générateur de secret JWT

1. 1

   Choisissez l'algorithme de signature

   Sélectionnez HS256, HS384 ou HS512. Le générateur applique instantanément la longueur de clé minimale de la RFC 7518 §3.2 pour cette variante HMAC — 32, 48 ou 64 octets — pour que vous n'ayez jamais à chercher le nombre ni à risquer une clé sous-dimensionnée.

2. 2

   Choisissez le format de sortie

   base64url est la valeur par défaut — l'encodage natif de JWT, compatible URL, sans remplissage. Passez à base64 standard si un chargeur l'attend, ou hex quand un système n'accepte que les caractères 0–f. Les trois encodent les mêmes octets aléatoires avec une entropie identique.

3. 3

   Révélez et copiez le secret

   Le secret est masqué par défaut pour le garder hors écran lors d'une démo ou d'un partage d'écran. Cliquez sur l'icône en forme d'œil pour le révéler, puis Copier pour récupérer la valeur brute ou Copier pour .env pour copier une ligne JWT_SECRET=… prête pour un fichier .env ou une variable de CI.

4. 4

   Régénérez au besoin

   Cliquez sur Régénérer pour un secret neuf et indépendant tiré de crypto.getRandomValues. Générez-en un par environnement — ne réutilisez jamais la même clé de signature en développement, en préproduction et en production.

5. 5

   Utilisez l'équivalent CLI ou passez à la signature

   Le panneau CLI affiche les commandes en une ligne correspondantes pour openssl, Node et Python pour un provisionnement scripté. Avec votre secret en main, signez un jeton avec l'encodeur JWT et confirmez la signature avec le décodeur JWT.

Erreurs courantes avec les secrets JWT

JWT_SECRET=mySuperSecret123  →  low entropy, brute-forceable

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0  →  32 random bytes

16-byte key with HS256  →  below the 32-byte minimum

32-byte key with HS256  →  meets RFC 7518 §3.2

Math.random()-based key  →  predictable, unsafe

crypto.getRandomValues key  →  full entropy

Service A: raw string · Service B: base64-decoded  →  signatures never match

Both services use the identical stored string  →  signatures verify

Same JWT_SECRET in dev, staging, prod  →  one leak breaks all

A unique secret per environment  →  blast radius contained

jwt.verify(token, secret)  →  accepts the token's alg

jwt.verify(token, secret, { algorithms: ['HS256'] })  →  pinned

Qui utilise cet outil

Provisionner un JWT_SECRET pour un nouveau service

Vous montez une API qui émet des jetons signés en HMAC ? Choisissez l'algorithme qu'utilise votre bibliothèque, copiez le secret sous forme de ligne JWT_SECRET=… et déposez-le dans l'environnement du service. Générez une clé distincte pour le développement, la préproduction et la production — ne partagez jamais un seul secret entre les environnements.

Faire la rotation d'un secret compromis ou vieillissant

Lorsqu'une clé est suspectée d'avoir fuité ou est simplement due pour rotation, générez un secret neuf ici, attribuez-lui un nouveau kid et déployez-le avec une fenêtre de chevauchement pour que les jetons actifs continuent de se vérifier jusqu'à leur expiration. En cas de compromission confirmée, faites la rotation immédiatement et retirez l'ancienne clé de l'ensemble accepté.

Remplacer une clé faible ou saisie à la main

Vous avez hérité d'un code dont le JWT_SECRET est une courte phrase ou une valeur d'exemple copiée ? Cette clé est forçable hors ligne. Générez un remplacement de 32 octets à pleine entropie, échangez-le derrière une fenêtre de rotation et fermez la faille de falsification de jeton avant qu'elle ne soit exploitée.

Scripter la génération de clé dans un pipeline

Vous avez besoin que la clé soit créée en CI ou dans un Dockerfile plutôt qu'à la main ? Utilisez la commande en une ligne openssl, Node ou Python du panneau CLI pour forger un secret de force égale dans votre script de provisionnement, et servez-vous de cette page pour comprendre les longueurs d'octets et les encodages que produit chaque commande.

Enseigner la signature JWT en toute sécurité

Faites découvrir à une équipe le fonctionnement de HS256 sans jamais exposer une vraie clé de production — générez un secret jetable à l'écran (masqué jusqu'à ce que vous le révéliez), signez un jeton d'exemple avec l'encodeur JWT et vérifiez-le avec le décodeur JWT pour que toute la boucle signer-vérifier soit visible.

Comparer les tailles de clé HS256, HS384 et HS512

Vous décidez quelle variante HMAC standardiser ? Basculez entre les algorithmes pour voir comment la longueur de clé requise et la chaîne encodée augmentent — 43, 64 et 86 caractères base64url — et choisissez le compromis robustesse / taille de jeton qui convient à votre système avant de l'inscrire en configuration.

Générer des clés pour le développement local

Vous avez besoin d'un secret rapide et valide pour faire tourner un flux d'authentification local ? Générez-en un en un clic, copiez-le pour .env, et vous êtes débloqué — avec une vraie clé issue d'un CSPRNG plutôt qu'un emplacement réservé que vous oublierez de remplacer avant le déploiement.

Comment fonctionne le générateur

crypto.getRandomValues (CSPRNG)

Les secrets sont générés en remplissant un Uint8Array avec crypto.getRandomValues, le générateur de nombres pseudo-aléatoires cryptographiquement sûr de Web Crypto. C'est la même source d'entropie qui sous-tend la génération de clés Web Crypto. Math.random n'est utilisé nulle part — il est statistiquement prévisible et inapte à toute clé cryptographique.

Dimensionnement de clé selon la RFC 7518 §3.2

Le nombre d'octets par algorithme suit l'exigence JSON Web Algorithms qu'une clé HMAC soit au moins de la taille de la sortie de hachage : 32 octets pour HS256 (SHA-256), 48 pour HS384 (SHA-384), 64 pour HS512 (SHA-512). Choisir l'algorithme fixe le minimum ; le générateur n'émettra pas de clé sous le plancher de la spécification.

Encodages RFC 4648 (base64url / base64 / hex)

Les octets bruts sont encodés avec les alphabets RFC 4648. base64url utilise l'alphabet compatible URL sans remplissage (32 octets → 43 car.), base64 standard utilise +, / et le remplissage = (→ 44 car.), et hex écrit deux caractères par octet (→ 64 car.). Changer de format réencode les mêmes octets — l'entropie sous-jacente est inchangée.

Pourquoi base64url est la valeur par défaut

Les composants JWT sont eux-mêmes encodés en base64url, et l'alphabet compatible URL sans remplissage signifie qu'un secret en base64url n'a jamais besoin d'échappement dans un en-tête, une URL ou un fichier de configuration. Les + et / et le = de fin du base64 standard peuvent casser dans ces contextes, donc base64url est la valeur par défaut prudente pour un JWT_SECRET.

Mise en forme de Copier pour .env

Copier pour .env émet JWT_SECRET= sur une seule ligne sans guillemets autour — la forme que les chargeurs de type dotenv analysent sans modification. Le secret brut n'inclut jamais de caractères qui nécessiteraient des guillemets dans un fichier .env, donc la ligne est sûre à coller telle quelle.

Commandes CLI de force équivalente, pas identiques octet par octet

Les commandes openssl rand -base64 N, Node randomBytes(N).toString('base64url') et Python secrets.token_urlsafe(N) du panneau CLI tirent toutes N octets aléatoires sûrs pour l'algorithme choisi. Elles produisent des clés de force égale, pas la même chaîne — openssl émet du base64 standard avec remplissage, donc l'alphabet et les caractères de fin diffèrent de la valeur par défaut base64url de cet outil.

Bonnes pratiques pour les secrets JWT

Adaptez la longueur de clé à l'algorithme

Utilisez au moins 32 octets pour HS256, 48 pour HS384 et 64 pour HS512, comme l'exige la RFC 7518 §3.2. Ce générateur le fait pour vous, mais si vous dimensionnez une clé à la main, ne descendez jamais sous la longueur de sortie de hachage — une clé HMAC sous-dimensionnée affaiblit la signature et peut être rejetée par les bibliothèques strictes.

Générez toujours avec un CSPRNG, jamais un mot de passe

Un secret JWT est un identifiant de machine que personne n'a besoin de mémoriser, alors dépensez toute l'entropie : utilisez une clé aléatoire cryptographiquement sûre, pas une phrase de passe, un mot du dictionnaire ou une chaîne saisie à la main. Les secrets choisis par un humain sont la cible la plus facile des attaques par force brute hors ligne qu'automatisent les outils de cassage JWT.

Utilisez un secret unique par environnement

Le développement, la préproduction et la production devraient chacun avoir leur propre JWT_SECRET. Partager une seule clé signifie qu'une fuite dans un environnement à faible enjeu forge des jetons partout, et rend la rotation tout ou rien. Générez un secret distinct ici pour chaque environnement et stockez chacun dans sa propre portée de gestionnaire de secrets.

Épinglez l'algorithme à la vérification

Du côté de la vérification, passez toujours une liste blanche d'algorithmes explicite — algorithms: ['HS256'] dans jsonwebtoken, algorithms=["HS256"] dans PyJWT — et ne faites jamais confiance au champ alg à l'intérieur du jeton. Accepter l'algorithme auto-déclaré du jeton ouvre la voie aux attaques classiques de confusion d'alg et de forge alg:none, quelle que soit la robustesse de votre secret.

Faites la rotation avec un en-tête kid et des clés qui se chevauchent

Étiquetez les jetons signés avec un identifiant de clé (kid) et publiez les clés actives via un point de terminaison JWKS pour pouvoir faire la rotation sans interruption : signez les nouveaux jetons avec la nouvelle clé tout en acceptant encore l'ancienne jusqu'à l'expiration de ses jetons. En cas de compromission suspectée, sautez le chevauchement et révoquez l'ancienne clé immédiatement.

Foire aux questions