JWT-Secret-Generator — HS256/384/512

Was ist ein JWT-Secret-Generator?

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

Hauptfunktionen

Durchgearbeitete Beispiele

Algorithmus: HS256 · Format: base64url

3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Algorithmus: HS512 · Format: base64url

k2Lp9XqA0mNbVcZ7rT4wYsHfGjUe8RoIdPlNkBvM3xQ1aWtCyZuS6FhEgJ (86 chars)

Auf „Für .env kopieren“ klicken

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Den CLI-Befehl anzeigen

openssl rand -base64 32

Auf das Augensymbol klicken

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

So nutzt du den JWT-Secret-Generator

1. 1

   Den Signieralgorithmus wählen

   Wähle HS256, HS384 oder HS512. Der Generator wendet sofort die minimale Schlüssellänge gemäß RFC 7518 §3.2 für diese HMAC-Variante an — 32, 48 oder 64 Byte — sodass du die Zahl nie nachschlagen oder einen zu kleinen Schlüssel riskieren musst.

2. 2

   Das Ausgabeformat wählen

   base64url ist der Standard — JWTs native URL-sichere Codierung ohne Padding. Wechsle zu Standard-base64, falls ein Loader es erwartet, oder zu hex, wenn ein System nur 0–f-Zeichen akzeptiert. Alle drei codieren dieselben Zufallsbytes mit identischer Entropie.

3. 3

   Das Secret einblenden und kopieren

   Das Secret ist standardmäßig maskiert, um es während einer Demo oder Bildschirmfreigabe vom Bildschirm fernzuhalten. Klicke auf das Augensymbol, um es einzublenden, dann auf „Kopieren“, um den Rohwert zu greifen, oder „Für .env kopieren“, um eine Zeile JWT_SECRET=… fertig für eine .env-Datei oder CI-Variable zu kopieren.

4. 4

   Bei Bedarf neu erzeugen

   Klicke auf „Neu erzeugen“ für ein frisches, unabhängiges Secret aus crypto.getRandomValues. Erzeuge eines pro Umgebung — verwende denselben Signierschlüssel nie über Entwicklung, Staging und Produktion hinweg wieder.

5. 5

   Das CLI-Äquivalent nutzen oder zum Signieren übergehen

   Das CLI-Panel zeigt die passenden openssl-, Node- und Python-Einzeiler für skriptgesteuerte Bereitstellung. Mit deinem Secret in der Hand signierst du ein Token mit dem JWT-Kodierer und bestätigst die Signatur mit dem JWT-Dekodierer.

Häufige Fehler bei JWT-Secrets

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

Wer dieses Tool nutzt

Ein JWT_SECRET für einen neuen Dienst bereitstellen

Startest du eine API, die HMAC-signierte Tokens ausstellt? Wähle den Algorithmus, den deine Bibliothek verwendet, kopiere das Secret als Zeile JWT_SECRET=… und setze es in die Umgebung des Dienstes. Erzeuge je einen eigenen Schlüssel für Entwicklung, Staging und Produktion — teile nie ein Secret über Umgebungen hinweg.

Ein kompromittiertes oder veraltetes Secret rotieren

Wenn ein Schlüssel als geleakt vermutet wird oder einfach zur Rotation ansteht, erzeuge hier ein frisches Secret, weise ihm ein neues kid zu und rolle es mit einem Überlappungsfenster aus, sodass aktive Tokens bis zu ihrem Ablauf weiter verifizieren. Bei bestätigtem Kompromittieren rotiere sofort und entferne den alten Schlüssel aus der akzeptierten Menge.

Einen schwachen oder von Hand getippten Schlüssel ersetzen

Eine Codebasis geerbt, deren JWT_SECRET eine kurze Phrase oder ein kopierter Beispielwert ist? Dieser Schlüssel ist offline per Brute Force knackbar. Erzeuge einen 32-Byte-Ersatz mit voller Entropie, tausche ihn hinter einem Rotationsfenster ein und schließe die Token-Fälschungslücke, bevor sie ausgenutzt wird.

Schlüsselerzeugung in einer Pipeline skripten

Den Schlüssel lieber in CI oder einem Dockerfile statt von Hand erzeugt? Verwende den openssl-, Node- oder Python-Einzeiler des CLI-Panels, um ein gleich starkes Secret in deinem Bereitstellungsskript zu prägen, und nutze diese Seite, um die Byte-Längen und Codierungen zu verstehen, die jeder Befehl erzeugt.

JWT-Signieren sicher vermitteln

Führe ein Team durch die Funktionsweise von HS256, ohne je einen echten Produktionsschlüssel offenzulegen — erzeuge ein Wegwerf-Secret auf dem Bildschirm (maskiert, bis du es einblendest), signiere ein Beispiel-Token mit dem JWT-Kodierer und prüfe es mit dem JWT-Dekodierer, sodass der gesamte Signier-und-Prüf-Kreislauf sichtbar wird.

HS256-, HS384- und HS512-Schlüsselgrößen vergleichen

Du entscheidest, welche HMAC-Variante du standardisieren willst? Wechsle zwischen den Algorithmen, um zu sehen, wie die erforderliche Schlüssellänge und die codierte Zeichenkette wachsen — 43, 64 und 86 base64url-Zeichen — und wähle den Kompromiss aus Stärke und Token-Größe, der zu deinem System passt, bevor du ihn in die Konfiguration übernimmst.

Schlüssel für die lokale Entwicklung erzeugen

Brauchst du ein schnelles, gültiges Secret, um einen lokalen Auth-Ablauf zum Laufen zu bringen? Erzeuge eines mit einem Klick, kopiere es für .env, und du bist entblockt — mit einem echten CSPRNG-Schlüssel statt eines Platzhalters, den du vor dem Deploy zu ersetzen vergisst.

So funktioniert der Generator

crypto.getRandomValues (CSPRNG)

Secrets werden erzeugt, indem ein Uint8Array mit crypto.getRandomValues gefüllt wird, dem kryptografisch sicheren Pseudo-Zufallszahlengenerator von Web Crypto. Es ist dieselbe Entropiequelle, die hinter der Schlüsselerzeugung von Web Crypto steht. Math.random wird nirgends verwendet — es ist statistisch vorhersehbar und für jeden kryptografischen Schlüssel ungeeignet.

Schlüsseldimensionierung nach RFC 7518 §3.2

Die Byte-Anzahl pro Algorithmus folgt der JSON-Web-Algorithms-Anforderung, dass ein HMAC-Schlüssel mindestens so groß wie die Hash-Ausgabe ist: 32 Byte für HS256 (SHA-256), 48 für HS384 (SHA-384), 64 für HS512 (SHA-512). Die Wahl des Algorithmus setzt das Minimum; der Generator gibt keinen Schlüssel unterhalb der Spezifikationsuntergrenze aus.

RFC-4648-Codierungen (base64url / base64 / hex)

Die Rohbytes werden mit den RFC-4648-Alphabeten codiert. base64url verwendet das URL-sichere Alphabet ohne Padding (32 Byte → 43 Zeichen), Standard-base64 verwendet +, / und =-Padding (→ 44 Zeichen), und hex schreibt zwei Zeichen pro Byte (→ 64 Zeichen). Das Wechseln des Formats codiert dieselben Bytes neu — die zugrunde liegende Entropie bleibt unverändert.

Warum base64url der Standard ist

JWT-Komponenten sind selbst base64url-codiert, und das URL-sichere Alphabet ohne Padding bedeutet, dass ein Secret in base64url in einem Header, einer URL oder einer Konfigurationsdatei nie escaped werden muss. Das +, / und abschließende = von Standard-base64 kann in diesen Kontexten brechen, daher ist base64url der konservative Standard für ein JWT_SECRET.

Formatierung für „Für .env kopieren“

„Für .env kopieren“ gibt JWT_SECRET= in einer einzigen Zeile ohne umschließende Anführungszeichen aus — die Form, die dotenv-artige Loader ohne Änderung parsen. Das rohe Secret enthält nie Zeichen, die in einer .env-Datei Anführungszeichen erfordern würden, sodass die Zeile sicher unverändert eingefügt werden kann.

Gleich starke CLI-Befehle, nicht byte-identisch

Die Befehle openssl rand -base64 N, Node randomBytes(N).toString('base64url') und Python secrets.token_urlsafe(N) des CLI-Panels ziehen alle N sichere Zufallsbytes für den gewählten Algorithmus. Sie erzeugen gleich starke Schlüssel, nicht dieselbe Zeichenkette — openssl gibt gepolstertes Standard-base64 aus, sodass sich Alphabet und Endzeichen vom base64url-Standard dieses Tools unterscheiden.

Best Practices für JWT-Secrets

Die Schlüssellänge an den Algorithmus anpassen

Verwende mindestens 32 Byte für HS256, 48 für HS384 und 64 für HS512, wie RFC 7518 §3.2 verlangt. Dieser Generator erledigt das für dich, aber wenn du einen Schlüssel von Hand dimensionierst, gehe nie unter die Länge der Hash-Ausgabe — ein zu kleiner HMAC-Schlüssel schwächt sowohl die Signatur als auch kann er von strengen Bibliotheken abgelehnt werden.

Immer mit einem CSPRNG erzeugen, nie mit einem Passwort

Ein JWT-Secret ist eine Maschinen-Anmeldung, die sich niemand merken muss, also gib die volle Entropie aus: Verwende einen kryptografisch sicheren Zufallsschlüssel, keine Passphrase, kein Wörterbuchwort und keine von Hand getippte Zeichenkette. Menschlich gewählte Secrets sind das leichteste Ziel für die Offline-Brute-Force-Angriffe, die JWT-Knack-Werkzeuge automatisieren.

Ein eindeutiges Secret pro Umgebung verwenden

Entwicklung, Staging und Produktion sollten je ein eigenes JWT_SECRET haben. Einen Schlüssel zu teilen bedeutet, dass ein Leak in einer risikoarmen Umgebung überall Tokens fälscht, und es macht die Rotation zu einer Alles-oder-nichts-Angelegenheit. Erzeuge hier ein separates Secret für jede Umgebung und speichere jedes in seinem eigenen Secrets-Manager-Bereich.

Den Algorithmus beim Prüfen festschreiben

Übergib auf der Prüfseite immer eine explizite Algorithmus-Whitelist — algorithms: ['HS256'] in jsonwebtoken, algorithms=["HS256"] in PyJWT — und vertraue nie dem alg-Feld im Token. Das selbstdeklarierte Algorithmus-Feld des Tokens zu akzeptieren, ermöglicht die klassischen alg-confusion- und alg:none-Fälschungsangriffe, egal wie stark dein Secret ist.

Mit einem kid-Header und überlappenden Schlüsseln rotieren

Versieh signierte Tokens mit einer Schlüsselkennung (kid) und veröffentliche aktive Schlüssel über einen JWKS-Endpunkt, sodass du ohne Ausfallzeit rotieren kannst: Signiere neue Tokens mit dem neuen Schlüssel, während du den alten noch akzeptierst, bis dessen Tokens ablaufen. Bei vermutetem Kompromittieren überspringe die Überlappung und widerrufe den alten Schlüssel sofort.

Häufig gestellte Fragen