So ist ein JSON Web Token aufgebaut
Ein JSON Web Token (JWT, RFC 7519) besteht aus drei Teilen, getrennt durch Punkte: Header, Payload und Signatur. Header und Payload sind JSON-Objekte, die mit Base64url kodiert sind – also mit dem Base64-Alphabet, in dem + und / durch - und _ ersetzt sind und das Füllzeichen = fehlt. Der Header nennt vor allem den Signaturalgorithmus (alg) und oft eine Schlüssel-ID (kid), die Payload enthält die eigentlichen Angaben, die sogenannten Claims.
Wichtig: Kodieren ist kein Verschlüsseln. Jeder, der ein Token sieht, kann Header und Payload lesen – genau das macht dieses Tool. Die Signatur schützt nur davor, dass jemand den Inhalt unbemerkt verändert. Passwörter, API-Schlüssel oder andere vertrauliche Daten gehören deshalb nicht in die Payload. Verschlüsselte Tokens (JWE) haben fünf statt drei Teile; bei ihnen ist nur der Header lesbar.
Die wichtigsten Claims
| Claim | Bedeutung | Hinweis |
|---|---|---|
iss | Aussteller | meist die Adresse des Identity Providers |
sub | Subjekt | eindeutige ID des Benutzers oder Dienstes |
aud | Zielgruppe | Zeichenkette oder Liste; der Empfänger muss sich darin wiederfinden |
exp | Ablaufzeit | ab diesem Zeitpunkt ungültig |
nbf | gültig ab | vorher ungültig |
iat | Ausstellungszeit | Zeitpunkt der Erstellung |
jti | Token-ID | eindeutige Kennung, z. B. für Sperrlisten |
Die Zeitangaben sind Sekunden seit dem 1. Januar 1970 (UTC), also Unix-Zeitstempel. Steht dort eine 13-stellige Zahl, hat der Aussteller vermutlich Millisekunden verwendet – ein häufiger Fehler. Einzelne Werte rechnen Sie mit dem Zeitstempel-Konverter um. OpenID Connect ergänzt weitere Claims wie azp, nonce, auth_time oder email; Anbieter wie Keycloak fügen eigene hinzu, etwa realm_access mit den Rollen.
Signaturalgorithmen im Überblick
| alg | Verfahren | Zur Prüfung nötig |
|---|---|---|
HS256, HS384, HS512 | HMAC mit SHA-2 | dasselbe Secret wie beim Aussteller |
RS256, RS384, RS512 | RSA (PKCS#1 v1.5) | öffentlicher RSA-Schlüssel |
PS256, PS384, PS512 | RSA-PSS | öffentlicher RSA-Schlüssel |
ES256, ES384, ES512 | ECDSA mit P-256, P-384, P-521 | öffentlicher EC-Schlüssel der passenden Kurve |
EdDSA | Ed25519 | öffentlicher Ed25519-Schlüssel |
Bei den HS-Verfahren teilen sich Aussteller und Prüfer ein Secret: Wer prüfen kann, kann auch Tokens erstellen. RFC 7518 verlangt dafür ein Secret, das mindestens so lang ist wie die Hash-Ausgabe, bei HS256 also 256 Bit. Die asymmetrischen Verfahren trennen das: Der Identity Provider signiert mit dem privaten Schlüssel, jeder Dienst prüft nur mit dem öffentlichen. Bei OpenID Connect finden Sie die öffentlichen Schlüssel als JWK-Set unter der Adresse jwks_uri, die im Dokument /.well-known/openid-configuration des Anbieters steht. Dieses JWK-Set können Sie oben direkt einfügen; das Tool wählt den Schlüssel anhand der kid aus dem Header.
Worauf Server bei der Prüfung achten müssen
Ein Dienst, der JWTs annimmt, sollte den erwarteten Algorithmus fest vorgeben, statt dem alg aus dem Token zu vertrauen. Sonst drohen zwei bekannte Angriffe: Tokens mit alg: none ganz ohne Signatur und die Verwechslung von RSA und HMAC, bei der ein Angreifer den öffentlichen RSA-Schlüssel als HMAC-Secret missbraucht. Außerdem gehören exp, nbf, iss und aud zu jeder Prüfung. Viele Bibliotheken erlauben eine kleine Zeittoleranz für abweichende Uhren; dieses Tool rechnet ohne Toleranz mit der Uhr Ihres Geräts.
Ein Token lässt sich auch ohne Tool in der Shell lesen. Base64url muss dafür in normales Base64 mit Padding umgewandelt werden:
p=$(printf '%s' "$TOKEN" | cut -d. -f2 | tr '_-' '/+')
while [ $(( ${#p} % 4 )) -ne 0 ]; do p="$p="; done
printf '%s' "$p" | base64 -d | jq .Für einzelne Base64-Werte eignet sich auch der Base64-Konverter. Wie Sie einen eigenen Identity Provider aufsetzen, zeigen die Anleitungen zu Keycloak, Zitadel und Pocket ID.
Häufige Fragen
Ist es sicher, ein Token hier einzufügen?
Das Tool dekodiert und prüft vollständig in Ihrem Browser; Token, Secret und Schlüssel werden weder übertragen noch gespeichert. Trotzdem gilt: Ein noch gültiges Token ist ein Zugangsschlüssel. Fügen Sie Produktivtokens grundsätzlich nur in Werkzeuge ein, denen Sie vertrauen, und lassen Sie sie nicht in Tickets oder Chats liegen.
Warum ist mein Token „gültig“, obwohl die Signatur nicht geprüft wurde?
Der Status oben bezieht sich nur auf die Zeitangaben exp und nbf. Ob das Token echt ist, zeigt erst die Signaturprüfung mit dem passenden Secret oder öffentlichen Schlüssel. Ein Token mit gültigen Zeiten, aber falscher Signatur ist wertlos.
Die Signatur ist ungültig – woran kann das liegen?
Meist passt der Schlüssel nicht: ein anderes Secret, ein älterer Schlüssel nach einer Rotation oder ein Secret, das beim Aussteller Base64-kodiert hinterlegt ist. Probieren Sie in diesem Fall den Schalter „Secret ist Base64-kodiert“. Bei ES-Algorithmen muss die Signatur außerdem aus den Werten R und S mit fester Länge bestehen; eine DER-kodierte Signatur, wie sie OpenSSL standardmäßig erzeugt, ist in einem JWT nicht gültig.
Kann ich ein abgelaufenes Token verlängern?
Nein. Jede Änderung an der Payload macht die Signatur ungültig. Ein neues Token stellt nur der Aussteller aus, bei OAuth 2.0 typischerweise über ein Refresh Token.
Welche Schlüsselformate versteht das Tool?
Öffentliche Schlüssel als PEM (BEGIN PUBLIC KEY oder BEGIN RSA PUBLIC KEY), X.509-Zertifikate (BEGIN CERTIFICATE), einzelne JWKs und ganze JWK-Sets. Private Schlüssel lehnt es ab – aus einem privaten PEM-Schlüssel erzeugen Sie den öffentlichen mit openssl pkey -in key.pem -pubout.