JWT-Generator
Signieren Sie ein eigenes JSON Web Token, um einen Endpunkt zu testen – mit denselben zwölf Algorithmen wie ein echter Aussteller, und ohne dass der Schlüssel Ihren Browser verlässt.
Signieren Sie ein eigenes Token, um einen Endpunkt zu testen. Alles wird auf dieser Seite berechnet.
Schlüssel und fertiges Token bleiben in Ihrem Browser: Beides wird nirgendwohin gesendet und steht auch in keinem geteilten Link.
Prüfen Sie dieses Token in Ihrem eigenen Code. Das Snippet richtet sich nach dem Algorithmus im Header.
Ein signiertes JSON Web Token erstellen
Meist geht es darum, Tokens zu lesen – dafür ist der JWT Decoder da. Manchmal braucht man die andere Richtung: ein Token, das es noch nicht gibt, um zu sehen, wie ein Dienst darauf reagiert. Eine Staging-API, die alles ablehnt, eine Middleware, die gerade entsteht, ein Test-Fixture, das in fünf Minuten ablaufen soll – sie alle brauchen ein Token, über das Sie bestimmen, und genau das signiert diese Seite.
Sie öffnet sich im Tab Token bauen. Alles dort – das Algorithmus-Menü, der Payload, der Schlüssel – wird von Ihrem eigenen Browser über crypto.subtle.sign zusammengesetzt und signiert. Zu keinem Zeitpunkt geht eine Anfrage an einen Server, der eingefügte Schlüssel bleibt also so privat wie der Tab, in den er getippt wurde.
Was am Ende in Header und Payload steht
Der Header wird für Sie geschrieben: der gewählte Algorithmus und typ: "JWT", dazu ein kid, wenn Sie das Feld ausgefüllt haben. Eine Schlüssel-ID ist wichtig, wenn der empfangende Dienst mehrere Schlüssel hält und einen davon beim Namen auswählt; bleibt das Feld leer, hat der Header zwei Felder.
Der Payload gehört Ihnen. Zwei Claims nicht: Beim Signieren wird iat immer mit der aktuellen Zeit gestempelt und exp aus dem Menü Läuft ab in gesetzt – fünf Minuten, eine Stunde, ein Tag, dreißig Tage oder gar nichts. Sobald das Token erscheint, steht im Payload-Feld genau das, was signiert wurde; die Zeitstempel, die Sie sehen, sind also die im Token. Wenn diese beiden Claims für Ihren Test entscheidend sind, erklärt der Ablauf-Prüfer, wie ein Server sie liest.
Den Algorithmus wählen
Die zwölf Algorithmen zerfallen in zwei Familien, und der Unterschied liegt nicht in der Stärke, sondern darin, wer den Schlüssel halten muss.
| Familie | Eingefügter Schlüssel | Passend, wenn |
|---|---|---|
| HS256 / HS384 / HS512 | Ein gemeinsames Secret, als Text oder Base64 | Ein Dienst stellt seine Tokens selbst aus und prüft sie selbst |
| RS256 / RS384 / RS512 | Privater PKCS#8-Schlüssel (PEM) oder JWK | Viele Dienste prüfen; sie sehen nur die öffentliche Hälfte |
| PS256 / PS384 / PS512 | Derselbe private RSA-Schlüssel | RSA mit dem neueren PSS-Padding, wenn der Empfänger es verlangt |
| ES256 / ES384 / ES512 | Ein privater EC-Schlüssel, P-256 / P-384 / P-521 | Sie wollen kurze Signaturen und kleine Schlüssel |
HS256 ist hier voreingestellt, weil meistens genau das getestet wird: ein Secret in einer Umgebungsvariablen, ein Dienst auf beiden Seiten. Sobald mehr als ein Dienst das Token prüfen muss, ist ein Public-Key-Verfahren die bessere Form, denn dem Prüfenden muss man dann nichts anvertrauen, womit sich Tokens ausstellen ließen.
Wofür ein erzeugtes Token taugt – und wofür nicht
Ein hier signiertes Token ist ein echtes Token: Fügen Sie es oben in den Decoder ein, drücken Sie Prüfen mit demselben Schlüssel, und die Signatur stimmt, weil die Seite sie genauso berechnet wie jede Bibliothek. Das macht es brauchbar für Fixtures, für das Nachstellen eines Fehlers mit einem abgelaufenen oder noch nicht gültigen Token und für die Frage, ob Ihre Middleware aud wirklich prüft oder nur liest.
Was es nicht ist: ein Weg hinein. Ein Token wird nur von einem Dienst akzeptiert, der den passenden Schlüssel hat; eines mit einem eigenen Secret zu signieren beweist also niemandem etwas. Genau dafür ist die Signatur da, und deshalb läuft der Unterschied zwischen Token und Session-Cookie darauf hinaus, wer was speichern muss.
Schlüssel, Formate und die Fehler, die sie verursachen
Für die HS-Familie fügen Sie das Secret als Klartext ein – oder setzen Sie das Häkchen bei Secret ist Base64, wenn Ihre Konfiguration es kodiert speichert. Dieselbe Zeichenkette ergibt roh und dekodiert völlig verschiedene Signaturen, was ein häufiger Grund dafür ist, dass ein Token an einer Stelle passt und an der anderen nicht.
Für RS, PS und ES nimmt der Browser ein PKCS#8-PEM – den Block, der mit -----BEGIN PRIVATE KEY----- beginnt – oder ein JWK, die JSON-Form, in der ein Schlüsselsatz ausgeliefert wird. Ein älterer -----BEGIN RSA PRIVATE KEY------Block ist PKCS#1 und muss zuerst umgewandelt werden. Fügen Sie versehentlich einen öffentlichen Schlüssel ein, sagt die Seite das, statt mit einer kryptischen Meldung zu scheitern: Ein öffentlicher Schlüssel kann eine Signatur prüfen, aber nie eine erzeugen.