JWT Generator
JSON Web Token erstellen, Header und Payload anpassen
Was ist JWT?
Der JWT-Generator erstellt JSON Web Tokens aus Header, Payload und Signaturparametern. Ein JWT besteht aus drei Base64URL-kodierten Teilen und wird häufig verwendet, um Claims wie Benutzer-ID, Rollen, Ablaufzeit, Aussteller oder Zielgruppe zwischen Diensten zu übertragen. Das Werkzeug ist hilfreich für API-Tests, lokale Entwicklung, Schulung, Debugging und das schnelle Erzeugen von Beispieltoken. Ein erzeugtes Token ist jedoch nur so vertrauenswürdig wie Schlüsselverwaltung, Algorithmuswahl, Ablaufzeit und Validierung auf Serverseite. Geheimnisse sollten nicht in öffentlichen Beispielen stehen, schwache Algorithmen oder zu lange Gültigkeit sind riskant, und sensible Daten gehören nicht unverschlüsselt in den Payload.
Verwendung
JWT-Erstellungsablauf
- Signaturalgorithmus auswählen (Standard: HS256)
- Geheimnis eingeben oder auf „Generieren“ klicken, um ein Signaturgeheimnis zu erstellen
- Payload-JSON bearbeiten und Standard-Claims über Schnellbuttons hinzufügen
- Ausstellungszeitpunkt (iat) und Ablaufzeit (exp) festlegen
- Auf „JWT-Token generieren“ klicken
- Generiertes Token für Tests oder Entwicklung kopieren
Token-Sicherheit
- Verwenden Sie starke Geheimnisse für HMAC-Algorithmen und schützen Sie private Schlüssel für RSA/ECDSA-Algorithmen.
- Setzen Sie realistische Werte für exp, iat, issuer und audience – ein syntaktisch gültiges JWT kann trotzdem unsicher sein oder von Ihrem Dienst abgelehnt werden.
Anwendungsfälle
Technisches Prinzip
Der JWT-Generator und der Parser sind gegenläufige Prozesse: Der Parser zerlegt die drei Teile, der Generator setzt sie zusammen. Kern ist die Berechnung des Signature-Segments. Zusammensetzungs-Flow: 1) Header-JSON bauen, z. B. {"alg":"HS256","typ":"JWT"}; 2) Payload-JSON mit Standard- und privaten Claims bauen; 3) Header und Payload separat Base64URL-kodieren, h_b64 und p_b64 erhalten; 4) h_b64 und p_b64 mit einem Punkt verbinden zu input = h_b64 + '.' + p_b64; 5) Signatur gemäß alg berechnen: HMAC-SHA256/384/512(secret, input); 6) Signaturergebnis Base64URL-kodieren; 7) Finaler Token = input + '.' + sig_b64. HMAC-SHA256-Signierung: Secret als Schlüssel (>= 32 Bytes) verwenden und HMAC über input laufen lassen. Intern führt HMAC zwei SHA-256-Runden aus: aus dem Secret werden ipad/opad-Schlüssel abgeleitet, dann SHA256(secret XOR ipad || msg) XOR opad berechnet. Schlüsselstärke: Die Länge des Secrets bestimmt die Sicherheit. RFC 7518 verlangt HS256-Schlüssel >= 256 Bit (32 Byte). In Produktion immer einen kryptographisch sicheren RNG nutzen (z. B. crypto.randomBytes); niemals Strings wie 'secret', 'password' oder '123456' verwenden. Häufige Fallstricke: 1) alg-Substitutionsangriff: Der Server muss alg streng validieren und darf alg nicht aus dem Token-Header lesen, um an den passenden Algorithmus zu dispatchen; 2) Schwache Schlüssel: Ein zu kurzes Secret lässt sich brute-forcen; 3) Payload-Manipulation: HMAC garantiert Integrität — ändert ein Angreifer das Payload, schlägt die Server-Verifikation fehl; 4) Token-Leak: JWTs sind nicht widerrufbar, ist ein Token erst raus, hilft nur Warten auf exp. Umfang dieses Tools: Es werden nur HS256/HS384/HS512 erzeugt. Asymmetrische Verfahren wie RS256 (RSA) und ES256 (ECDSA) erfordern einen privaten Schlüssel beim Aussteller und werden von einem Backend-Signaturdienst oder einem dedizierten SDK ausgeführt, nicht von dieser Seite.
- HMAC-SHA256-Signierungskern: HMAC(secret, header_b64 + '.' + payload_b64), gibt eine 256-Bit-Signatur aus und kodiert sie Base64URL.
- HS256-Schlüssellänge muss >= 32 Bytes (256 Bit) betragen; empfohlen wird die Erzeugung mit crypto.getRandomValues oder crypto.randomBytes — kurze Schlüssel sind anfällig für Wörterbuchangriffe.
- Dieses Tool erzeugt ausschließlich HMAC-signierte Tokens (HS256/HS384/HS512). Asymmetrische Verfahren wie RS256 oder ES256 erfordern einen privaten Schlüssel auf der Aussteller-Seite und werden hier nicht erzeugt — dafür ist ein Backend-Signaturdienst oder ein dediziertes SDK nötig.
- iat/exp/nbf sind alle Unix-Timestamps in Sekunden (nicht Millisekunden); Server verlangen üblicherweise exp > jetzt(), nbf <= jetzt() und iat <= jetzt().
- alg=none-Angriff: Serverseitig eine Whitelist erlaubter Algorithmen pflegen (z. B. ['HS256']); den Algorithmus niemals dynamisch aus dem Token-Header wählen. Viele JWT-Bibliotheken erlaubten historisch alg=none als Standard — das ist eine bekannte Schwachstelle.
- Ein JWT kann nach Ausstellung nicht widerrufen werden — die einzige Maßnahme ist das Warten auf exp. Für aktiven Widerruf eine jti-Blacklist pflegen oder ein kurzlebiges Access-Token plus Refresh-Token verwenden.
Beispiele
Einfaches HS256-Beispiel
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Schlüssel: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4UEigene Ablaufzeit mit iat und exp
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
Header und Payload werden Base64URL-kodiert, mit einem Punkt verbunden und anschließend per HMAC-SHA256 mit dem geteilten Secret signiert. Das Token-Feld zeigt den fertigen dreigeteilten String, bereit für den Authorization-Header.Benutzerdefinierte Claims
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}FAQ
Wird das JWT lokal generiert?
Ja. Header, Payload und Signatur werden im Browser über die Web Crypto API berechnet. Das Signiergeheimnis bzw. der private Schlüssel verlässt die Seite nie. Behandle das fertige Token aber als Daten, die geloggt oder offengelegt werden können – besonders, wenn du es in einen echten Service einfügst.
Welche Signaturalgorithmen werden unterstützt?
Dieses Tool erzeugt HS256, HS384 und HS512 (HMAC mit geteiltem Secret). Asymmetrische Verfahren wie RS256/RS384/RS512 (RSA) und ES256/ES384/ES512 (ECDSA) werden hier nicht erzeugt — wenn dein Verifier sie verlangt, nutze einen Backend-Signaturdienst oder ein dediziertes SDK. Vermeide alg=none in Produktion: jeder vernünftige Verifier weist unsignierte Tokens zurück.
Was kommt in den Payload?
Standard-Claims wie sub, iss, aud, exp, iat, nbf plus alle Custom-Claims, die dein Service nutzt. Halte den Payload klein – JWTs reisen in Headern und blähen jede Anfrage auf. Lege niemals Passwörter, vollständige Kreditkartennummern oder andere Geheimnisse hinein; der Payload ist Base64URL-codiert, nicht verschlüsselt.
Wie setze ich die Ablaufzeit?
Setze exp auf den Unix-Zeitstempel (in Sekunden, nicht Millisekunden), zu dem das Token ungültig werden soll. Tokens ohne exp sind technisch erlaubt, aber die meisten produktiven Services bestehen darauf. Übliche Werte: 5–60 Minuten für Access Tokens, 7–30 Tage für Refresh Tokens.
Warum schlägt die Verifizierung meines JWT fehl?
Häufige Ursachen: alg im Header passt nicht zur Erwartung des Verifiers; Secret/Key ist anders; Payload-Claims (iss, aud) stimmen nicht mit der Server-Konfiguration überein; der Zeitversatz zwischen Aussteller und Verifier überschreitet die zulässige Toleranz (typisch ±60 s); eine manuelle Bearbeitung hat die Base64URL-Codierung beschädigt (keine Zeilenumbrüche einfügen).
Wird mein Geheimnis oder privater Schlüssel an einen Server gesendet?
Nein. Das Signieren passiert komplett im Browser über Web Crypto. Trotzdem: Füge nie einen produktiven Signing-Key in ein Web-Tool ein – teste mit einem Nicht-Produktions-Key und signiere dann in deinem echten Backend.
HS256 oder RS256 – was sollte ich nehmen?
HS256 erfordert, dass beide Seiten ein Geheimnis teilen, also nur sinnvoll, wenn derselbe Service ausstellt und prüft. Mit RS256 (oder ES256) hält der Aussteller einen privaten Schlüssel, während jeder Konsument mit dem öffentlichen Schlüssel verifiziert – die richtige Wahl für OAuth/OIDC und jede Multi-Service-Architektur. Dieses Tool erzeugt nur Tokens der HS-Familie; für RS256/ES256 ist ein Backend-Signaturdienst oder ein dediziertes SDK erforderlich.