JWT-Encoder
Ein Token aus Claims bauen — und wirklich signieren · läuft in diesem Tab, wird nie irgendwohin gesendet
Header
Payload
Signaturschlüssel
Der Schlüssel wird benutzt und verworfen — nie in diesem Browser gespeichert, nie irgendwohin gesendet.
Ein Signaturschlüssel erzeugt Tokens, die deine Systeme akzeptieren. Für Produktionsschlüssel besser die eigene Umgebung.
HS256
Signiertes Token
Hier erscheint das signierte Token. Dafür wird nichts hochgeladen — die Signatur berechnet dieser Browser.
So funktioniert der JWT-Encoder
Ein JWT-Encoder, der ein echt signiertes Token erzeugt statt einer Base64-Attrappe. Schreibe Header und Payload als JSON, wähle einen Algorithmus und füge das gemeinsame Secret für ein HS-Verfahren oder einen privaten PKCS#8-Schlüssel für RS, PS oder ES ein — die Signatur berechnet die WebCrypto deines eigenen Browsers. Ablauf, Ausstellzeit und „nicht vor“ lassen sich per Preset stempeln, sodass du nie wieder einen Epoch-Wert von Hand umrechnest.
Schreibe Header und Payload als JSON, wähle einen Algorithmus, und das Token wird beim Tippen zusammengesetzt und signiert. Die Ablauf-Presets stempeln iat, exp und auf Wunsch nbf aus einem einzigen Moment in den Payload, sodass die drei nie um eine Sekunde auseinanderliegen können — genau die Art Fehler, die erst in der Uhrzeit-Toleranz eines anderen Systems auffällt.
alg wird immer aus dem gewählten Algorithmus geschrieben, egal was im Header steht. Das ist keine Bequemlichkeit: Ein Header, der einen Algorithmus behauptet, während die Signatur mit einem anderen erzeugt wurde, ist der Ausgangspunkt der bekanntesten JWT-Schwachstelle, und es gibt kein legitimes Token, das dieses Werkzeug deshalb verweigern würde. Jedes andere Header-Feld bleibt genau so, wie du es geschrieben hast.
HS-Secrets, die kürzer sind als der Hash, werden standardmäßig abgelehnt — RFC 7518 verlangt 32 Byte für HS256, 48 für HS384 und 64 für HS512, und ein Browser signiert bereitwillig mit vier Zeichen, obwohl sich das Ergebnis offline in Sekunden knacken lässt. Die Prüfung lässt sich abschalten, denn ein schwaches Token nachzubauen ist manchmal genau die Aufgabe.
Der Signaturschlüssel wird behandelt wie der Prüfschlüssel im Decoder, und noch sorgfältiger: nie in localStorage geschrieben, nie beim Neuladen wiederhergestellt, nie in einem Analytics-Ereignis, und es gibt kein Backend, das ihn empfangen könnte. Ein Signaturschlüssel ist das gefährlichste Geheimnis in einem System mit JWTs — für einen Produktionsschlüssel bleibt es die bessere Gewohnheit, Tokens in der eigenen Umgebung zu erzeugen.
Häufige Fragen
Ist es sicher, einen Signaturschlüssel hier einzufügen?
Der Schlüssel wird in deinem eigenen Tab benutzt und verworfen — nie gespeichert, nie in einem Analytics-Ereignis, und es gibt kein Backend, das ihn empfangen könnte. Dennoch: Ein Signaturschlüssel ist das gefährlichste Geheimnis in jedem System mit JWTs, denn wer ihn hat, kann Tokens erzeugen, die deine Dienste akzeptieren. Für einen Produktionsschlüssel bleibt es die bessere Gewohnheit, Tokens in der eigenen Umgebung zu erzeugen; dieses Werkzeug ist für Entwicklung, Tests und Lernen gedacht.
Mit welchen Algorithmen kann es signieren?
HS256, HS384 und HS512 mit einem gemeinsamen Secret sowie RS256/384/512, PS256/384/512 und ES256/384/512 mit einem privaten Schlüssel als PKCS#8-PEM-Block oder privatem JWK. Es erzeugt auch das ungesicherte `alg: none`-Token, deutlich als beweislos gekennzeichnet — denn so prüfst du, dass dein Verifizierer es ablehnt.
Warum wird mein kurzes Secret abgelehnt?
RFC 7518 verlangt einen HMAC-Schlüssel, der mindestens so lang ist wie der Hash: 32 Byte für HS256, 48 für HS384, 64 für HS512. Browser signieren bereitwillig mit einem Secret aus vier Zeichen, und das entstehende Token lässt sich offline in Sekunden knacken. Der Encoder blockiert das standardmäßig und lässt dich es übergehen, denn ein schwaches Token nachzubauen ist manchmal genau die Aufgabe.
Kann es den Algorithmus in meinem Header überschreiben?
Es schreibt `alg` immer aus dem gewählten Algorithmus, und das mit Absicht. Ein Header, der einen Algorithmus behauptet, während die Signatur mit einem anderen erzeugt wurde, ist kein Token, sondern der Ausgangspunkt der bekanntesten JWT-Schwachstelle. Jedes andere Header-Feld — `kid`, `cty`, beliebige eigene — bleibt genau so, wie du es geschrieben hast.