Wer mit modernen Web-APIs, Single-Page-Apps oder OAuth arbeitet, stößt unweigerlich auf JWT – den JSON Web Token. Diese kompakten, kryptografisch signierten Zeichenketten sind heute das Rückgrat zahlloser Authentifizierungssysteme. Dieser Ratgeber erklärt, wie ein JWT aufgebaut ist, was die einzelnen Teile bedeuten und worauf du bei der Sicherheit achten musst.
Was ist ein JSON Web Token?
Ein JWT (JSON Web Token, ausgesprochen "jot") ist ein offener Standard (RFC 7519) zur sicheren Übertragung von Informationen zwischen zwei Parteien. Der typische Einsatz: Nach dem Login stellt ein Server dem Client ein JWT aus. Bei jeder weiteren Anfrage schickt der Client dieses Token mit, und der Server kann anhand der Signatur prüfen, dass es echt und unverändert ist – ohne eine Sitzung in einer Datenbank nachschlagen zu müssen.
Diese Zustandslosigkeit (Stateless) ist der große Vorteil: Der Server muss keine Session-Daten speichern, was die Skalierung über viele Server hinweg vereinfacht. Das ganze Vertrauen steckt in der Signatur des Tokens.
Der Aufbau: Drei Teile, getrennt durch Punkte
Ein JWT besteht aus drei Base64url-kodierten Abschnitten, die durch Punkte getrennt sind: Header.Payload.Signatur. Ein typisches Token sieht aus wie ein langer, scheinbar zufälliger String mit zwei Punkten darin. Diese drei Teile lassen sich getrennt betrachten und dekodieren – genau das macht der JWT Decoder, der Header, Payload und Ablaufzeit lokal im Browser lesbar macht.
1. Der Header
Der Header enthält Metadaten über das Token, vor allem den verwendeten Signaturalgorithmus. Typische Werte sind HS256 (HMAC mit SHA-256, symmetrisch) oder RS256 (RSA mit SHA-256, asymmetrisch). Außerdem steht hier der Typ ("typ": "JWT"). Diese Information sagt dem Empfänger, wie er die Signatur überprüfen muss.
2. Die Payload
Die Payload enthält die eigentlichen Daten – die sogenannten Claims. Das sind Aussagen über den Nutzer und das Token selbst. Standardisierte Claims sind unter anderem:
- sub (Subject) – die eindeutige ID des Nutzers
- iss (Issuer) – wer das Token ausgestellt hat
- exp (Expiration) – der Zeitpunkt, ab dem das Token ungültig ist
- iat (Issued At) – wann das Token erstellt wurde
- aud (Audience) – für welchen Empfänger es bestimmt ist
Dazu kommen oft eigene Claims wie Rolle, E-Mail oder Berechtigungen. Wichtig zu verstehen: Diese Daten sind nur kodiert, nicht verschlüsselt.
3. Die Signatur
Die Signatur ist der Sicherheitsanker. Sie wird gebildet, indem Header und Payload mit einem geheimen Schlüssel über den im Header angegebenen Algorithmus verarbeitet werden. Ändert ein Angreifer auch nur ein Zeichen in der Payload, passt die Signatur nicht mehr – der Server erkennt die Manipulation und lehnt das Token ab.
Der wichtigste Sicherheitshinweis: Kodiert ist nicht verschlüsselt
Der häufigste Irrtum bei JWT: Viele halten den Inhalt für geheim, weil er kryptisch aussieht. Tatsächlich ist die Payload nur Base64url-kodiert und für jeden, der das Token besitzt, im Klartext lesbar. Genau deshalb darf ein JWT niemals Passwörter, Kreditkartendaten oder andere Geheimnisse in der Payload enthalten.
Die Signatur garantiert nur die Integrität (das Token wurde nicht verändert) und die Authentizität (es stammt vom richtigen Aussteller) – nicht die Vertraulichkeit. Du kannst das selbst überprüfen: Gib ein beliebiges Token in den JWT Decoder ein und du siehst die komplette Payload im Klartext, ganz ohne Schlüssel.
Häufige Sicherheitsfallen
- "alg": "none": Manche fehlerhafte Implementierungen akzeptieren Tokens ohne Signatur. Ein sicherer Server muss diesen Algorithmus strikt ablehnen.
- Fehlende Ablaufprüfung: Wird der exp-Claim nicht überprüft, bleiben gestohlene Tokens unbegrenzt gültig. Halte die Lebensdauer kurz und nutze Refresh-Tokens.
- Schwaches Secret: Bei HS256 hängt die gesamte Sicherheit am geheimen Schlüssel. Ein kurzes oder erratbares Secret macht die Signatur wertlos – erzeuge es mit einem Passwort-Generator als langen Zufallswert.
- Tokens im Browser: Ein im LocalStorage abgelegtes JWT ist bei einer XSS-Lücke auslesbar. HttpOnly-Cookies sind oft die sicherere Wahl.
JWT richtig debuggen
Im Entwicklungsalltag musst du oft schnell sehen, was in einem Token steckt – welche Rolle ein Nutzer hat, wann das Token abläuft, von welchem Issuer es stammt. Ein Decoder zerlegt das Token in seine drei Teile und zeigt Header und Payload als formatiertes JSON. Achte darauf, ein lokal arbeitendes Werkzeug zu verwenden: Ein Produktiv-Token gehört nicht in einen Online-Dienst, der es an einen fremden Server sendet. Der JWT Decoder rechnet vollständig im Browser, sodass das Token dein Gerät nicht verlässt.
Fazit
JSON Web Tokens sind ein elegantes, zustandsloses Verfahren für Authentifizierung in modernen Anwendungen. Wer ihren Aufbau aus Header, Payload und Signatur versteht, vermeidet die typischen Fehler – allen voran den Trugschluss, kodierte Daten seien geheim. Zerlege deine Tokens beim Entwickeln mit dem JWT Decoder; weitere Developer- und Security-Helfer findest du in der Webtools-Übersicht.