JWT erstellen und prüfen: HS256, HS384 und HS512

So verwenden Sie es

Schreiben Sie den Header (JSON) und den Payload (JSON). Verwenden Sie iat auf jetzt setzen, nbf auf jetzt setzen oder exp setzen in, um die Zeiten einzutragen.
Wählen Sie den Algorithmus und tippen Sie den Geheimschlüssel ein. Wählen Sie unter Kodierung des Schlüssels Base64, wenn der Schlüssel in Base64 geschrieben ist.
Kopieren Sie das Token. Es besteht aus drei Teilen, die durch Punkte getrennt sind: dem Header, dem Payload und der Signatur.
Fügen Sie ein Token in Zu prüfendes Token ein, um zu sehen, ob seine Signatur zum Schlüssel oben passt.

So wird ein JWT signiert

Ein JSON Web Token (RFC 7519) besteht aus einem Header und einem Payload. Beide sind als JSON geschrieben, in Base64url kodiert (RFC 7515) und durch einen Punkt verbunden. Die Signatur ist ein HMAC dieser beiden Teile, gebildet mit dem Geheimschlüssel (RFC 7518, Abschnitt 3.2). Der Header nennt den Algorithmus im Feld alg, und diese Seite setzt dieses Feld auf den Algorithmus, den Sie wählen.

Die Seite schreibt jedes JSON-Objekt vor dem Kodieren in seiner kompakten Form. Die signierten Bytes sind daher die kompakte Form dessen, was Sie eingegeben haben, nicht der Text mit seinen Leerzeichen und Zeilenumbrüchen. Jede Stelle, die das Token prüft, arbeitet mit den Bytes, die sie erhält. Daher ist das Token in beiden Fällen gültig.

Signiereingabe = BASE64URL(Header) . BASE64URL(Payload)
Signatur       = HMAC-SHA-256(Geheimschlüssel, Signiereingabe)
                 (HS384 und HS512 verwenden HMAC-SHA-384 und HMAC-SHA-512)
Token          = Signiereingabe . BASE64URL(Signatur)

Die Zeiten im Payload

Die Angaben iat (issued at, ausgestellt am), nbf (not before, nicht vor) und exp (expiration time, Ablaufzeit) sind NumericDates: Sekunden seit dem 1. Januar 1970, 00:00 UTC (RFC 7519, Abschnitte 2 und 4.1). Ein Token wird am oder nach exp nicht akzeptiert und vor nbf ebenfalls nicht. Die Schaltflächen schreiben die Zeit aus der Uhr Ihres Geräts, daher ergibt eine falsche Uhr eine falsche Zeit.

Was das Prüfen tut und was nicht

Beim Prüfen wird die HMAC von Header und Payload genau so neu berechnet, wie sie eingefügt wurden, und mit der Signatur verglichen. Die Prüfung lehnt alg none und jeden Algorithmus außer HS256, HS384 und HS512 ab, damit ein Token keine schwächere Prüfung wählen kann.

Sie prüft nicht, was die Angaben bedeuten: ob iss der erwartete Aussteller ist oder ob aud Ihren Dienst nennt. Ihre Anwendung muss das prüfen, wie RFC 8725 empfiehlt.

Rechenbeispiel: HS256 mit dem Schlüssel your-256-bit-secret

Mit dem Header {"alg": "HS256", "typ": "JWT"}, dem Payload {"sub": "1234567890", "name": "Ada Lovelace", "iat": 1516239022} und dem UTF-8-Schlüssel your-256-bit-secret erstellt die Seite dieses Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMn0.nmm0qepYRjhNji3O-jq8Pvcr7l_me1_bomw4EJucQCU

Die Prüfung mit demselben Schlüssel ergibt eine gültige Signatur. Das Token hat keinen Anspruch exp oder nbf, daher kann keine Zeit es ungültig machen. Die Prüfung mit einem anderen Schlüssel meldet, dass die Signatur nicht passt.

Häufig gestellte Fragen

Wird mein Schlüssel an einen Server gesendet?

Nein. Das Token wird in Ihrem Browser mit der eingebauten Schnittstelle SubtleCrypto signiert. Der Schlüssel bleibt nur geöffnet, solange die Seite offen ist: Er wird nicht gesendet, gespeichert oder protokolliert.

Warum zeigt die Seite, dass die Signatur passt, aber meine Bibliothek lehnt das Token ab?

Die Bibliothek prüft vielleicht die Zeiten exp oder nbf, die Zielgruppe oder den Aussteller, oder sie liest den Schlüssel in einer anderen Kodierung. Lesen Sie den Schlüssel so, wie Ihre Bibliothek es tut, als UTF-8 oder als Base64, und vergleichen Sie die Zeiten mit einer richtig gehenden Uhr.

Warum wird alg none abgelehnt?

Ein Token mit alg none hat keine Signatur, daher kann jeder eines schreiben. Ein Dienst muss es ablehnen. Diese Seite lehnt es bei der Prüfung ab, und ihr Signieren schreibt immer einen HMAC-Algorithmus.

Wie lang sollte der Schlüssel sein?

Mindestens so lang wie die Hash-Ausgabe: 32 Bytes für HS256, 48 für HS384 und 64 für HS512 (RFC 7518, Abschnitt 3.2). Die Seite warnt, wenn der Schlüssel kürzer ist.

Kann diese Seite RS256- oder ES256-Token erstellen?

Nein. Sie signiert und prüft nur mit einem gemeinsamen Schlüssel, mit HS256, HS384 oder HS512. Token, die mit einem privaten RSA- oder ECDSA-Schlüssel signiert wurden, brauchen diesen Schlüssel, den diese Seite nicht annimmt.

Wann sollte ich für den Schlüssel Base64 wählen?

Nur wenn der Schlüssel in Base64 geschrieben ist, etwa der Wert k eines JSON Web Key. Sonst wird der Schlüssel als UTF-8-Text genau so gelesen, wie Sie ihn eingegeben haben, Leerzeichen eingeschlossen.

Quellen

Zahlen und Text zuletzt geprüft: Dienstag, 10. November 2026.