Gratis JWT-secretgenerator — HS256/384/512

Wat is een JWT-secretgenerator?

// 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))"

Belangrijkste functies

Uitgewerkte voorbeelden

Algoritme: HS256 · Formaat: base64url

3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Algoritme: HS512 · Formaat: base64url

k2Lp9XqA0mNbVcZ7rT4wYsHfGjUe8RoIdPlNkBvM3xQ1aWtCyZuS6FhEgJ (86 chars)

Klik op "Kopiëren voor .env"

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Toon het CLI-commando

openssl rand -base64 32

Klik op het oogpictogram

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

De JWT-secretgenerator gebruiken

1. 1

   Kies het ondertekeningsalgoritme

   Selecteer HS256, HS384 of HS512. De generator past meteen de minimale sleutellengte volgens RFC 7518 §3.2 voor die HMAC-variant toe — 32, 48 of 64 bytes — zodat je het getal nooit hoeft op te zoeken of een te kleine sleutel riskeert.

2. 2

   Kies het uitvoerformaat

   base64url is de standaard — JWT's eigen URL-veilige codering zonder padding. Schakel naar standaard base64 als een loader het verwacht, of hex wanneer een systeem alleen 0–f-tekens accepteert. Alle drie coderen dezelfde willekeurige bytes met identieke entropie.

3. 3

   Onthul en kopieer het secret

   Het secret is standaard gemaskeerd om het buiten beeld te houden tijdens een demo of schermdeling. Klik op het oogpictogram om het te onthullen, gebruik dan Kopiëren om de ruwe waarde te pakken of Kopiëren voor .env om een JWT_SECRET=…-regel te kopiëren die klaar is voor een .env-bestand of CI-variabele.

4. 4

   Genereer opnieuw indien nodig

   Klik op Opnieuw genereren voor een nieuw, onafhankelijk secret uit crypto.getRandomValues. Genereer er één per omgeving — hergebruik nooit dezelfde ondertekeningssleutel over ontwikkeling, staging en productie.

5. 5

   Gebruik het CLI-equivalent of ga door naar ondertekenen

   Het CLI-paneel toont de bijbehorende openssl-, Node- en Python-oneliners voor scriptmatige provisioning. Met je secret in de hand onderteken je een token met de JWT-encoder en bevestig je de handtekening met de JWT-decoder.

Veelvoorkomende JWT-secret-fouten

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

Wie gebruikt deze tool

Een JWT_SECRET voor een nieuwe service leveren

Een API opzetten die HMAC-ondertekende tokens uitgeeft? Kies het algoritme dat je bibliotheek gebruikt, kopieer het secret als een JWT_SECRET=…-regel, en plaats het in de omgeving van de service. Genereer een aparte sleutel voor ontwikkeling, staging en productie — deel nooit één secret over omgevingen.

Een gecompromitteerd of verouderd secret roteren

Wanneer een sleutel vermoedelijk is gelekt of simpelweg toe is aan rotatie, genereer je hier een nieuw secret, ken je het een nieuwe kid toe, en rol je het uit met een overlapvenster zodat live tokens blijven verifiëren tot ze verlopen. Bij een bevestigde compromittering roteer je meteen en verwijder je de oude sleutel uit de geaccepteerde set.

Een zwakke of met de hand getypte sleutel vervangen

Een codebase geërfd waarvan de JWT_SECRET een korte zin of een gekopieerde voorbeeldwaarde is? Die sleutel is offline brute-forcebaar. Genereer een vervanging van 32 bytes met volledige entropie, wissel hem in achter een rotatievenster, en sluit het gat voor tokenvervalsing voordat het wordt uitgebuit.

Sleutelgeneratie scripten in een pipeline

Moet de sleutel in CI of een Dockerfile worden gemaakt in plaats van met de hand? Gebruik de openssl-, Node- of Python-oneliner uit het CLI-paneel om een even sterk secret in je provisioningscript aan te maken, en gebruik deze pagina om de bytelengtes en coderingen te begrijpen die elk commando produceert.

JWT-ondertekening veilig onderwijzen

Loop een team door hoe HS256 werkt zonder ooit een echte productiesleutel bloot te stellen — genereer een wegwerpsecret op het scherm (gemaskeerd tot je het onthult), onderteken een voorbeeldtoken met de JWT-encoder, en verifieer het met de JWT-decoder zodat de hele onderteken-en-verifieer-lus zichtbaar is.

HS256-, HS384- en HS512-sleutelgroottes vergelijken

Beslissen op welke HMAC-variant je standaardiseert? Wissel tussen de algoritmen om te zien hoe de vereiste sleutellengte en gecodeerde string groeien — 43, 64 en 86 base64url-tekens — en kies de afweging tussen sterkte en tokengrootte die bij je systeem past voordat je hem in de configuratie vastlegt.

Sleutels genereren voor lokale ontwikkeling

Een snel, geldig secret nodig om een lokale auth-flow draaiende te krijgen? Genereer er een met een klik, kopieer het voor .env, en je bent gedeblokkeerd — met een echte CSPRNG-sleutel in plaats van een placeholder die je voor de deploy vergeet te vervangen.

Hoe de generator werkt

crypto.getRandomValues (CSPRNG)

Secrets worden gegenereerd door een Uint8Array te vullen met crypto.getRandomValues, de cryptografisch veilige pseudowillekeurige getallengenerator van Web Crypto. Het is dezelfde entropiebron die Web Crypto-sleutelgeneratie ondersteunt. Math.random wordt nergens gebruikt — het is statistisch voorspelbaar en ongeschikt voor elke cryptografische sleutel.

RFC 7518 §3.2-sleuteldimensionering

Het aantal bytes per algoritme volgt de JSON Web Algorithms-eis dat een HMAC-sleutel minstens zo groot is als de hash-uitvoer: 32 bytes voor HS256 (SHA-256), 48 voor HS384 (SHA-384), 64 voor HS512 (SHA-512). Het selecteren van het algoritme stelt het minimum in; de generator geeft geen sleutel onder de specvloer uit.

RFC 4648-coderingen (base64url / base64 / hex)

De ruwe bytes worden gecodeerd met de RFC 4648-alfabetten. base64url gebruikt het URL-veilige alfabet zonder padding (32 bytes → 43 tekens), standaard base64 gebruikt +, / en =-padding (→ 44 tekens), en hex schrijft twee tekens per byte (→ 64 tekens). Van formaat wisselen hercodeert dezelfde bytes — de onderliggende entropie blijft onveranderd.

Waarom base64url de standaard is

JWT-componenten zijn zelf base64url-gecodeerd, en het URL-veilige alfabet zonder padding betekent dat een secret in base64url nooit hoeft te worden ge-escaped in een header, een URL of een configuratiebestand. De + en / en de eind-= van standaard base64 kunnen in die contexten breken, dus base64url is de behoudende standaard voor een JWT_SECRET.

Opmaak van Kopiëren voor .env

Kopiëren voor .env geeft JWT_SECRET= uit op één regel zonder omringende aanhalingstekens — de vorm die dotenv-achtige loaders zonder aanpassing parsen. Het ruwe secret bevat nooit tekens die in een .env-bestand aanhalingstekens zouden vereisen, dus de regel is veilig om as-is te plakken.

Gelijkwaardig sterke CLI-commando's, niet byte-identiek

De openssl rand -base64 N-, Node randomBytes(N).toString('base64url')- en Python secrets.token_urlsafe(N)-commando's uit het CLI-paneel trekken alle N veilige willekeurige bytes voor het gekozen algoritme. Ze produceren even sterke sleutels, niet dezelfde string — openssl geeft gepadde standaard base64 uit, dus het alfabet en de eindtekens verschillen van de base64url-standaard van deze tool.

Best practices voor JWT-secrets

Stem de sleutellengte af op het algoritme

Gebruik minstens 32 bytes voor HS256, 48 voor HS384 en 64 voor HS512, zoals RFC 7518 §3.2 vereist. Deze generator doet het voor je, maar als je een sleutel met de hand dimensioneert, ga dan nooit onder de hash-uitvoerlengte — een te kleine HMAC-sleutel verzwakt de handtekening en kan door strikte bibliotheken worden afgewezen.

Genereer altijd met een CSPRNG, nooit een wachtwoord

Een JWT-secret is een machine-inloggegeven dat niemand hoeft te onthouden, dus besteed de volledige entropie: gebruik een cryptografisch veilige willekeurige sleutel, geen wachtwoordzin, woordenboekwoord of met de hand getypte string. Door mensen gekozen secrets zijn het makkelijkste doelwit voor de offline brute-force-aanvallen die JWT-kraaktools automatiseren.

Gebruik een uniek secret per omgeving

Ontwikkeling, staging en productie zouden elk hun eigen JWT_SECRET moeten hebben. Eén sleutel delen betekent dat een lek in een omgeving met lage inzet overal tokens vervalst, en het maakt rotatie alles-of-niets. Genereer hier een apart secret voor elke omgeving en bewaar elk in zijn eigen secrets-manager-scope.

Pin het algoritme wanneer je verifieert

Geef aan de verifiërende kant altijd een expliciete algoritme-whitelist mee — algorithms: ['HS256'] in jsonwebtoken, algorithms=["HS256"] in PyJWT — en vertrouw nooit het alg-veld in het token. Het zelf-gedeclareerde algoritme van het token accepteren maakt de klassieke alg-confusion- en alg:none-vervalsingsaanvallen mogelijk, hoe sterk je secret ook is.

Roteer met een kid-header en overlappende sleutels

Voorzie ondertekende tokens van een sleutel-identificator (kid) en publiceer actieve sleutels via een JWKS-endpoint, zodat je zonder downtime kunt roteren: onderteken nieuwe tokens met de nieuwe sleutel terwijl je de oude nog accepteert tot zijn tokens verlopen. Bij een vermoede compromittering sla je de overlap over en trek je de oude sleutel meteen in.

Veelgestelde vragen