Was ein JWT ist
Ein JSON Web Token (JWT, RFC 7519) ist eine kompakte Zeichenkette mit JSON-Header und Payload, optional geschützt durch eine Signatur oder authentifizierte Verschlüsselung. Die übliche signierte Form besteht aus drei Base64URL-Segmenten, getrennt durch Punkte:
base64url(header) . base64url(payload) . base64url(signature)
Der Payload enthält typischerweise Claims wie Subject (sub), Audience (aud), Ablaufzeit (exp) und anwendungsspezifische Felder. Weil der Payload eines signierten (nicht verschlüsselten) JWT nur kodiert ist, kann jeder mit dem Token die Claims lesen. Die Signatur erkennt Manipulation und bestätigt mit gemeinsamem Geheimnis oder öffentlichem Schlüssel, wer das Token ausgestellt hat.
Untersuchen Sie ein Beispieltoken mit dem Werkzeug JWT dekodieren—alleiniges Dekodieren beweist nicht, dass die Signatur gültig ist.
Unterwerkzeuge in dieser Familie
- JWT dekodieren — teilt Header und Payload und dekodiert sie mit Base64URL, damit Sie Algorithmen und Claims lokal im Browser lesen können.
- JWT HS256 signieren — erzeugt ein Token aus JSON-Payload und gemeinsamem Geheimnis mit HMAC-SHA256.
- JWT HS256 verifizieren — berechnet die HMAC-SHA256-Signatur mit Ihrem Geheimnis neu und meldet, ob sie übereinstimmt.
Typischer Lernweg: einen Wegwerf-Payload signieren, dekodieren und Claims prüfen, dann mit demselben Geheimnis verifizieren. Jede Änderung am Payload sollte die Verifikation scheitern lassen.
HS256 und die Rolle von HMAC
HS256 bedeutet HMAC-SHA256 über Header- und Payload-Segmente. Aussteller und Prüfer teilen ein Geheimnis. Das passt zu First-Party-APIs und einfachen Session-Tokens. Es passt schlecht, wenn viele nicht vertrauenswürdige Clients Tokens prüfen müssen, ohne das Issuer-Geheimnis zu besitzen—dort brauchen Sie asymmetrische Algorithmen (RS256, ES256) mit öffentlichem JWKS.
HS256-Verifikation ist nur so stark wie die Geheimnisverwaltung. Ein Geheimnis in einer öffentlichen Mobile-App oder einem Frontend-Bundle erlaubt jedem, Tokens zu fälschen.
Zur zugrunde liegenden MAC-Konstruktion siehe auch den Hub HMAC, insbesondere HMAC SHA-256.
Claims, die Sie sorgfältig behandeln sollten
exp / nbf / iat. Ablauf- und Not-Before-Fenster verhindern unbegrenzte Wiederverwendung. Verifier müssen abgelaufene Tokens ablehnen; Decoder, die nur JSON ausgeben, prüfen die Zeit nicht für Sie.
alg. Der Header wirbt den Algorithmus an. Hardcodieren Sie den erwarteten Algorithmus im Verifier (z. B. nur HS256). Historische Schwachstellen akzeptierten alg: none oder wechselten von RS256 zu HS256 und behandelten einen öffentlichen Schlüssel als HMAC-Geheimnis.
aud und iss. Audience- und Issuer-Prüfungen verhindern, dass Tokens für einen Dienst von einem anderen akzeptiert werden.
Sensible Daten im Payload. Bevorzugen Sie undurchsichtige Kennungen statt Roh-Personendaten in unverschlüsselten JWTs. Logs, Browser-Historie und Referer-Header können Tokens leaken.
Dekodieren versus Verifizieren
| Operation | Beweist Lesbarkeit | Beweist Authentizität |
|---|---|---|
| Dekodieren | Ja (bei nicht verschlüsseltem JWT) | Nein |
| HS256 verifizieren | Braucht Geheimnis | Ja, wenn Geheimnis korrekt und Vergleich solide ist |
Verifizieren Sie immer in Anwendungspfaden, die Aktionen autorisieren. Dekodieren im Debugger ist für Menschen; kryptografische Prüfung ist für Maschinen, die Zugriffsentscheidungen treffen.
Base64URL-Details
JWT nutzt Base64URL ohne Padding in der klassischen Serialisierung. Das unterscheidet sich von Standard-Base64 (+// vs -/_). Alphabet-Mischung beim manuellen Neuaufbau von Tokens ist eine häufige Ursache ungültiger Signaturfehler. Bevorzugen Sie Bibliotheks-APIs für die Kodierung statt handgebauter String-Konkatenation in Produktion.
Häufige Fehlerbilder
- Uhrenschiefstand: gerade ausgestelltes Token wirkt „noch nicht gültig“ oder schon abgelaufen—erlauben Sie eine kleine Toleranz, wenn Ihre Plattform sie dokumentiert.
- UTF-8 und JSON-Kanonisierung: erneutes Signieren nach Pretty-Print ändert Bytes und bricht Signaturen.
- Geheimnis-Mismatch zwischen Umgebungen (Staging vs Produktion).
- Dekodier-Erfolg mit Login-Erfolg verwechseln.
- Passwörter oder Kartendaten in JWT-Claims legen.
Grenzen und Umgebung
Diese Werkzeuge konzentrieren sich auf HS256-Lernen und Debugging. Sie implementieren nicht den vollen JOSE-Stack (JWE-Verschlüsselung, jeden JWA-Algorithmus oder JWKS-Föderation). Clientseitige Verarbeitung hält Beispieltokens auf dem Gerät; kleben Sie trotzdem keine Produktions-Session-Tokens in gemeinsame Maschinen.
Zusammenfassung
JWTs verpacken Claims in einer kompakten, signierten Zeichenkette. Dieser Hub lässt Sie Header und Payload dekodieren, mit HS256 signieren und HMAC-SHA256-Signaturen prüfen. Lesen Sie Claims vorsichtig, verifizieren Sie vor dem Vertrauen, schützen Sie gemeinsame Geheimnisse und wählen Sie asymmetrische Algorithmen, wenn Verifier den Issuer-Schlüssel nicht teilen sollen.