Werden das Secret oder das erzeugte Token an einen Server gesendet?

Nein. Signiert wird in deinem Browser mit der Web Crypto API. Secret, Header, Payload und Token werden an keinen Server gesendet, landen nicht in Analytics-Events und werden nicht gespeichert, wenn du die Seite schließt.

Darf ich hier das Produktions-Secret verwenden?

Nein. Auch wenn alles im Browser läuft: Wer das Produktions-Secret hat, kann für jeden Nutzer ein Token ausstellen. Richte für Tests ein eigenes Secret in der Testumgebung ein oder nimm das hier erzeugte.

Ich habe ein Token erzeugt und die API lehnt es ab. Was prüfe ich?

Prüfe, ob das Secret dasselbe ist wie im Backend, auch ob es dort Base64-kodiert gespeichert ist; ob der in der API konfigurierte Algorithmus zu dem des Tokens passt; ob exp in der Zukunft und nbf in der Vergangenheit liegt; und ob iss und aud zu dem passen, was die API erwartet.

Warum kann ich keine RS256- oder ES256-Tokens erzeugen?

Weil man dafür einen Private Key in den Browser einfügen müsste. Solche Schlüssel gehören nur auf den Server, der die Tokens ausstellt. Für APIs, die RS256 prüfen, hol dir ein Token beim Testanbieter und prüfe die Claims mit dem JWT Decoder.

Wie lege ich fest, wann das Token abläuft?

Nutze die Kurzbefehle exp +15 Min., +1 Std., +1 Tag oder +7 Tage, die ab jetzt rechnen, oder ändere exp im JSON in Unix-Sekunden. Der Kurzbefehl exp abgelaufen erzeugt ein bereits abgelaufenes Token.

Es ist eine eindeutige Token-ID. APIs nutzen jti, um Wiederverwendung zu blockieren oder ein bestimmtes Token zu widerrufen. Der Kurzbefehl erzeugt bei jedem Klick eine neue UUID v4.

Wann aktiviere ich die Option für ein Base64-Secret?

Wenn das Backend das Secret Base64-kodiert speichert und vor der Nutzung dekodiert, wie manche Spring-Konfigurationen und Java-Bibliotheken. Nutzt das Backend den Text des Secrets direkt, lass die Option aus.

JWT Generator

Stelle Header und Claims zusammen, gib das Secret ein und kopiere ein mit HS256, HS384 oder HS512 signiertes JWT. Damit testest du Login, Zugriffsprofile und Ablaufzeiten, ohne vom Identity Provider abhängig zu sein.

Nur für Tests. Nimm ein Test-Secret oder das hier erzeugte Zufalls-Secret, niemals das Produktions-Secret. Signiert wird in deinem Browser, und nichts wird an einen Server gesendet.

Algorithmus

HMAC mit SHA-256, SHA-384 oder SHA-512. Wer das Token prüft, braucht dasselbe Secret.

Testprofil

Header

Das alg im Header folgt dem gewählten Algorithmus.

Payload (Claims)

Claim hinzufügen

Secret

Das Secret ist Base64-kodiert

Erzeugtes Token

Das Token erscheint hier, sobald Header, Payload und Secret gültig sind.

Du hast ein Token bekommen und willst sehen, was drinsteht?

JWT Decoder öffnen

Wie benutzt man den JWT Generator?

Claims zusammenstellen

Wähle ein Testprofil oder bearbeite das Payload-JSON. Die Kurzbefehle fügen relatives exp, iat, jti und andere gängige Claims hinzu.

Secret eingeben

Nutze dasselbe Secret wie dein Test-Backend oder erzeuge ein zufälliges in der passenden Größe für den Algorithmus.

Token ansehen

Das Token wird bei jeder Änderung neu signiert, ganz ohne Button. Die Zusammenfassung zeigt, wann es abläuft.

Kopieren und testen

Kopiere das Token oder den fertigen Authorization-Header und nutze ihn in Postman, curl oder einem automatisierten Test.

Wozu ein Test-JWT erzeugen

Sich für jedes Testszenario beim Identity Provider anzumelden, ist nicht immer praktisch. Mit einem hier erzeugten Token testest du die API mit jedem gewünschten Profil, auch mit schwer nachstellbaren Fällen wie einem bereits abgelaufenen Token oder einem ohne bestimmte Rolle. Das funktioniert, wenn dein Test-Backend Tokens mit einem dir bekannten HMAC-Secret prüft.

Szenarien, für die sich ein Test-Token lohnt

Admin und normaler Nutzer mit demselben sub, um zu prüfen, ob die Route Nutzer ohne die Rolle blockiert
Ein abgelaufenes Token, um sicherzustellen, dass die API 401 liefert und das Frontend ein neues Token anfordert
Ein Token mit nbf in der Zukunft, um die Ablehnung eines noch nicht gültigen Tokens zu testen
Ein Token ohne roles-Claim oder mit unvollständigem Scope, um die 403-Antwort zu testen
Ein Token mit dem aud einer anderen API, um zu bestätigen, dass die API fremde Tokens ablehnt
Eine mit einem anderen Secret erstellte Signatur, um zu bestätigen, dass die API manipulierte Tokens ablehnt

HS256, RS256 und ES256: der Unterschied

HS256 nutzt ein gemeinsames Secret: Derselbe Wert signiert und prüft, wer validiert, kann also auch Tokens ausstellen. RS256 nutzt ein RSA-Schlüsselpaar: Der Anbieter signiert mit dem Private Key, und APIs prüfen mit dem Public Key, der veröffentlicht werden darf. ES256 macht dasselbe mit elliptischen Kurven, mit deutlich kleineren Schlüsseln und Signaturen. Anbieter wie Keycloak, Auth0 und Cognito signieren standardmäßig mit RS256.

Dieser Generator signiert bewusst nur mit HMAC. Für RS256 oder ES256 müsste man einen Private Key in den Browser einfügen, und ein Private Key sollte den Server, der die Tokens ausstellt, nicht verlassen. Um eine API zu testen, die RS256 prüft, hol dir das Token aus der Testumgebung des Anbieters.

So wird die HMAC-Signatur berechnet

Der Generator kodiert Header und Payload in base64url, verbindet beide mit einem Punkt und berechnet das HMAC dieses Textes mit dem Secret. Das Ergebnis, ebenfalls in base64url, wird zum dritten Teil des Tokens. Darum ergibt jede Änderung am Payload, selbst ein Leerzeichen, eine andere Signatur, und das Backend lehnt ein verändertes Token ab, solange das Secret unbekannt ist.

Länge des Secrets

RFC 7518 verlangt ein Secret, das mindestens so lang ist wie die Hash-Ausgabe: 32 Bytes für HS256, 48 für HS384 und 64 für HS512. Ein Secret wie passwort123 signiert problemlos, lässt sich aber aus einem abgefangenen Token per Brute Force ermitteln. Der Button Zufalls-Secret erzeugt eines in der Mindestgröße für den gewählten Algorithmus.

So schickst du das Token in einer Anfrage mit

Am gängigsten ist der Authorization-Header mit dem Präfix Bearer. Der Button Authorization kopieren kopiert die fertige Zeile. Mit curl sieht das so aus:

curl -H "Authorization: Bearer DEIN_TOKEN" https://api.test.beispiel.de/bestellungen

Häufig gestellte Fragen zum JWT Generator

Typische Fragen beim Erzeugen von JWTs für Tests.