JWT Generator

Willkommen beim JWT Generator, einem schnellen und kostenlosen Online-Tool zur Erstellung signierter JSON Web Tokens. Egal, ob Sie einen Authentifizierungs-Flow testen, eine API entwickeln, eine Integration debuggen oder lernen möchten, wie JWTs unter der Haube funktionieren – dieser Generator gibt Ihnen die volle Kontrolle über den Token-Header, die Payload-Claims und den HMAC-Signaturalgorithmus. Erzeugen Sie mit einem Klick einen gültigen HS256, HS384 oder HS512 Token und untersuchen Sie jedes Segment Seite an Seite.

Was ist ein JSON Web Token?

Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Format für Anmeldedaten, das durch RFC 7519 definiert ist. Ein JWT überträgt Claims über ein Subjekt zwischen zwei Parteien und beweist seine Integrität durch eine kryptographische Signatur. Da das Token in sich geschlossen ist, kann der Empfänger es validieren, ohne beim Aussteller rückfragen zu müssen — eine Eigenschaft, die JWTs zum Rückgrat der zustandslosen Authentifizierung für moderne Web- und Mobilanwendungen macht.

Jedes JWT besteht aus drei base64url-kodierten Teilen, die mit Punkten verbunden sind:

• Header — ein JSON-Objekt, das den Token-Typ (typ) und den Signaturalgorithmus (alg) deklariert.
• Payload — ein JSON-Objekt, das die Claims enthält, wie z. B. die Benutzer-ID, die Ablaufzeit und beliebige benutzerdefinierte Daten.
• Signature — eine HMAC- oder RSA-Signatur über den kodierten Header und die Payload, die diese vor Manipulationen schützt.

Wie der JWT Generator funktioniert

Dieses Tool folgt exakt dem JWT-Signaturrezept aus RFC 7519 §7.1:

1. Serialisieren Sie das Header-JSON in seine kompakte Form (keine Leerzeichen) und kodieren Sie es mit base64url.
2. Verfahren Sie ebenso mit dem Payload-JSON.
3. Verknüpfen Sie beide mit einem Punkt als Trennzeichen. Dies ist die Signatureingabe.
4. Berechnen Sie den HMAC der Signatureingabe mit Ihrem Secret und dem gewählten SHA-2-Algorithmus.
5. Kodieren Sie die resultierenden Signatur-Bytes mit base64url.
6. Verknüpfen Sie alles als header.payload.signature.

Was diesen Generator unterscheidet

• Farbvisualisierung der drei Segmente — Header (Rosa), Payload (Lila), Signatur (Cyan), damit Sie jeden Teil sofort erkennen können.
• Quick Claims-Palette — Ein-Klick-Einfügen von iss, sub, aud, iat, nbf und jti.
• Ablauf-Helfer — Voreingestellte Buttons für 1 Stunde, 1 Tag, 7 Tage oder 30 Tage, die automatisch den korrekten Unix-Zeitstempel berechnen.
• Live-Token-Vorschau — Der kodierte Header und die Payload werden während der Eingabe aktualisiert, sodass Sie sehen können, wie jede Änderung das Token beeinflusst.
• Smarte Header-Synchronisierung — Das Umschalten des Algorithmus aktualisiert automatisch das alg-Feld des Headers.
• Base64-Secret-Umschalter — Wenn Ihr Secret als Base64 gespeichert ist (die JWS-Konvention für binäre Schlüssel), aktivieren Sie die Option und das Tool dekodiert es vor dem Signieren.
• Kopier-Buttons pro Segment — Kopieren Sie Header, Payload, Signatur oder das vollständige Token unabhängig voneinander.
• Claim-Zusammenfassung — Erkannte Standard-Claims werden mit einer Beschreibung und gegebenenfalls einem menschenlesbaren Zeitstempel aufgelistet.

Den richtigen Algorithmus wählen

Die drei HMAC-Varianten, die dieses Tool unterstützt, sind funktional identisch, außer für den zugrunde liegenden SHA-2-Hash und die Signaturlänge:

• HS256 — HMAC mit SHA-256. 256-Bit-Signatur. Der Standard für fast jede JWT-Bibliothek und die am weitesten verbreitete Wahl.
• HS384 — HMAC mit SHA-384. 384-Bit-Signatur. Etwas größere Sicherheitsmarge gegen künftige Kryptoanalyse.
• HS512 — HMAC mit SHA-512. 512-Bit-Signatur. Nützlich, wenn Richtlinien den längsten Standard-Hash erfordern.

Alle drei beruhen auf einem gemeinsamen Secret, das sowohl der Signierer als auch der Verifizierer besitzen. RFC 7518 §3.2 verlangt, dass der Schlüssel mindestens so lang wie die Hash-Ausgabe ist: 256 Bit für HS256, 384 Bit für HS384, 512 Bit für HS512.

Standardmäßig registrierte Claims

RFC 7519 §4.1 definiert einen kleinen Satz von Standard-Claims, die JWT-Aussteller und -Verifizierer erkennen sollten. Sie sind alle optional, werden aber weitgehend unterstützt:

• iss (Issuer) — identifiziert, wer das Token erstellt hat. Oft eine URL oder ein Dienstname.
• sub (Subject) — identifiziert, worum es in dem Token geht, typischerweise eine Benutzer-ID.
• aud (Audience) — identifiziert den Empfänger, für den das Token bestimmt ist. Kann ein einzelner String oder ein Array sein.
• exp (Expiration Time) — Unix-Zeitstempel, nach dem das Token abgelehnt werden muss.
• nbf (Not Before) — Unix-Zeitstempel, vor dem das Token nicht akzeptiert werden darf.
• iat (Issued At) — Unix-Zeitstempel, der aufzeichnet, wann das Token erstellt wurde.
• jti (JWT ID) — eine eindeutige Kennung, mit der Token widerrufen oder einzeln nachverfolgt werden können.

So verwenden Sie dieses Tool

1. Signaturalgorithmus wählen — klicken Sie auf HS256, HS384 oder HS512. Der Header wird automatisch angepasst.
2. Header bearbeiten (optional) — der Standard-Header enthält alg und typ. Fügen Sie eine benutzerdefinierte kid (Key ID) hinzu, falls Ihr Verifizierer diese benötigt.
3. Payload erstellen — geben Sie Ihre Claims als JSON ein oder nutzen Sie die Quick Claims-Buttons, um Standardfelder einzufügen. Der Ablauf-Helfer schreibt einen korrekten Unix-Zeitstempel für die gewählte relative Dauer.
4. Secret festlegen — geben Sie Ihr gemeinsames HMAC-Secret ein. Nutzen Sie das Augensymbol, um es anzuzeigen. Wenn Ihr Secret base64-kodiert ist, aktivieren Sie das Kontrollkästchen, damit das Tool es vor dem Signieren dekodiert.
5. JWT generieren — klicken Sie auf JWT generieren. Das vollständige Token, die drei Segmentkarten, das Strukturdiagramm und die Zusammenfassung der erkannten Claims werden zusammen gerendert.
6. Kopieren, was Sie brauchen — nutzen Sie die segmentweisen Kopieren-Buttons oder den Button "Token kopieren", um den kodierten Wert in Postman, curl oder Ihre Client-App zu übernehmen.

Häufige Anwendungsfälle

Authentifizierung und Autorisierung

• Ausgabe von Access-Tokens nach einem erfolgreichen Login.
• Kodierung der Benutzeridentität (sub) plus Rollen- oder Berechtigungs-Claims.
• Signieren kurzlebiger Token (15–60 Minuten) und deren bedarfsgerechte Erneuerung.

API-Integrationstests

• Erstellen von Mock-Tokens, um zu testen, wie Ihre API auf abgelaufene, in der Zukunft datierte oder fehlerhafte Claims reagiert.
• Generieren von Fixture-JWTs für Unit-Tests und CI-Pipelines.
• Reproduzieren von produktionsnahen Token in einer lokalen Umgebung, ohne den echten Authentifizierungsserver zu nutzen.

Single Sign-On (SSO) Debugging

• Vergleich eines bekanntermaßen funktionierenden JWT mit einem, das Ihr Provider sendet, um Abweichungen von der Spezifikation zu finden.
• Prüfung des Signaturalgorithmus und der Key ID (kid), die von einem Upstream-Aussteller verwendet werden.

Häufig gestellte Fragen

Ist das hier erstellte JWT ein echtes, gültiges Token?

Ja. Das Token wird mit HMAC über den kanonisch kodierten Header und die Payload signiert. Jede JWT-Bibliothek, die dasselbe Secret wie Sie verwendet, wird es erfolgreich validieren.

Warum sieht mein Token identisch aus wie das, was ich anderswo generiere?

Weil JWTs deterministisch sind: Bei gleichem Header, gleicher Payload und gleichem Secret erzeugt jede konforme Bibliothek exakt denselben String. Wenn Sie einen Unterschied sehen, prüfen Sie, ob die JSON-Serialisierungsreihenfolge, die Schreibweise der Schlüssel und die Secret-Kodierung übereinstimmen.

Kann ich ein JWT dekodieren, um zu überprüfen, was ich generiert habe?

Ja. Kombinieren Sie dieses Tool mit einem JWT-Decoder, um die Segmente zu inspizieren. Das Dekodieren macht nur den base64url-Schritt rückgängig — für die Verifizierung der Signatur wird weiterhin das Secret benötigt.

Warum wird mein Secret als zu kurz abgelehnt?

RFC 7518 empfiehlt einen Schlüssel mit mindestens der Länge der Hash-Ausgabe: 256 Bit für HS256. Das Tool selbst erzwingt keine Mindestlänge, aber ein korrekt arbeitender Verifizierer könnte kurze Schlüssel ablehnen. Verwenden Sie im realen Einsatz ein zufällig generiertes Secret mit 32+ Bytes.

Unterstützt dieses Tool RS256, ES256 oder EdDSA?

Noch nicht — dieses Tool konzentriert sich auf HMAC-basierte Algorithmen, da diese nur einen gemeinsamen String benötigen. Asymmetrische Algorithmen (RS*, PS*, ES*, EdDSA) erfordern Schlüsselpaare und PEM-Handling, die besser in spezialisierten Tools aufgehoben sind.

Werden mein Secret und meine Payload an den Server gesendet?

Das Formular wird über HTTPS übermittelt, um die Signatur zu berechnen. Nichts wird über die Dauer der Anfrage hinaus protokolliert oder gespeichert. Geben Sie hier dennoch keine Produktions-Secrets ein — behandeln Sie es wie eine öffentliche Testumgebung.

Zusätzliche Ressourcen

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7518 - JSON Web Algorithms (JWA)
• JSON Web Token - Wikipedia