JWT verständlich erklärt: Aufbau und Sicherheitsaspekte

JSON Web Tokens (JWT) sind ein kompakter, URL-sicherer Standard (RFC 7519) zur Übertragung von Informationen zwischen zwei Parteien im JSON-Format. Sie werden im modernen Web-Engineering (wie z. B. dem Backend von allerate.dev) primär für die zustandslose Authentifizierung (Stateless Authentication) und den sicheren Austausch von Benutzerdaten (Claims) eingesetzt.

Technisch ist ein JWT nichts anderes als drei Base64Url-codierte JSON-Objekte, die durch Punkte verbunden und mit einer kryptografischen Signatur abgesichert sind. Wichtig zu verstehen: Codierung ist keine Verschlüsselung – jeder kann den Inhalt lesen, aber dank der Signatur niemand unbemerkt verändern.

Der dreiteilige Aufbau eines JWTs

Ein JWT besteht aus drei Abschnitten, die jeweils durch einen Punkt (.) voneinander getrennt sind:

graph LR
    H["HEADER<br/>alg, typ"] --> P["PAYLOAD<br/>Claims: sub, exp, role"]
    P --> S["SIGNATURE<br/>HMAC/RSA über Header+Payload"]

Wenn Sie ein fertiges Token betrachten, sehen Sie eine lange Zeichenkette, die aus Base64Url-codierten Zeichen besteht (z. B. eyJhbGciOi...).

1. Header (Kopfdaten)

Der Header gibt den Typ des Tokens an und definiert den verwendeten kryptografischen Signatur-Algorithmus (z. B. HMAC SHA256 oder RSA).

• Beispiel: {"alg": "HS256", "typ": "JWT"}

2. Payload (Nutzdaten)

Die Payload enthält die eigentlichen Datenübertragungen, sogenannte Claims (Ansprüche). Es gibt registrierte Standard-Claims (wie sub für den Betreff, exp für die Ablaufzeit) sowie frei definierbare, anwendungsspezifische Claims (z. B. Benutzerrollen).

• Beispiel: {"sub": "1234567890", "name": "Admin", "role": "ROLE_ADMIN", "exp": 1718876400}

3. Signature (Signatur)

Die Signatur stellt sicher, dass das Token auf dem Transportweg nicht manipuliert wurde. Sie wird erzeugt, indem der codierte Header, die codierte Payload und ein geheimer Schlüssel (Secret / Private Key) mit dem im Header definierten Algorithmus gehasht werden.

• Prinzip: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

---

Die wichtigsten registrierten Claims im Überblick

Die Payload kann beliebige Daten enthalten, doch der Standard definiert reservierte Claims, die jede Bibliothek versteht und prüfen kann:

Claim	Bedeutung	Beispielwert
iss	Issuer – wer das Token ausgestellt hat	https://auth.allerate.dev
sub	Subject – eindeutige Nutzer-/Objekt-ID	1234567890
aud	Audience – für welchen Empfänger das Token gilt	api.allerate.dev
exp	Expiration – Ablaufzeitpunkt (Unix-Timestamp)	1718876400
iat	Issued At – Ausstellungszeitpunkt	1718872800
nbf	Not Before – frühester Gültigkeitsbeginn	1718872800

Die zeitbasierten Claims (exp, iat, nbf) sind klassische Epoch-Timestamps. Ein Server muss exp zwingend gegen die aktuelle Zeit prüfen – sonst bleiben gestohlene Token unbegrenzt gültig.

---

Signatur-Algorithmen: symmetrisch vs. asymmetrisch

Die Signatur entsteht durch ein Hashverfahren in Kombination mit einem Schlüssel. Welcher Algorithmus passt, hängt von der Architektur ab:

Verfahren	Algorithmus	Schlüssel	Eignung
Symmetrisch	HS256 (HMAC + SHA-256)	Ein gemeinsames Secret	Monolith, ein vertrauenswürdiger Dienst
Asymmetrisch	RS256 (RSA)	Privat (signieren) + öffentlich (prüfen)	Microservices, viele Prüfer
Asymmetrisch	ES256 (ECDSA)	Wie RS256, kürzere Schlüssel	Mobile, performance-kritisch

Faustregel: Sobald mehr als ein Dienst Token prüfen muss, ist ein asymmetrisches Verfahren (RS256/ES256) die robustere Wahl, weil der private Signaturschlüssel den Identity-Provider nie verlässt.

---

Sicherheitsrisiken beim Einsatz von JWTs

Beim Entwurf von Authentifizierungssystemen müssen Entwickler fatale Sicherheitslücken proaktiv vermeiden:

• Sensible Daten in Claims: Da die Payload unverschlüsselt übertragen wird, dürfen niemals Passwörter, Bankdaten oder sensible personenbezogene Daten im JWT hinterlegt werden.
• Der “alg: none” Angriff: Ältere oder schlecht konfigurierte Bibliotheken erlaubten es Angreifern, den Algorithmus im Header auf none zu setzen und die Signatur zu löschen. Ein Server, der diese Validierung nicht blockiert, akzeptiert manipulierte Token als gültig.
• Schwache Secrets: Wird für die Signatur (z. B. HS256) ein kurzes, erratbares Passwort als Secret genutzt, können Angreifer das Token offline per Brute-Force entschlüsseln und den Signaturschlüssel errechnen.
• Fehlende Ablaufprüfung: Wird exp serverseitig nicht validiert, bleibt ein einmal ausgestelltes Token unbegrenzt gültig – auch nach einem Logout oder Passwortwechsel.

---

Häufige Fehler und ihre Folgen

Fehler	Folge	Gegenmassnahme
alg: none akzeptiert	Token-Fälschung ohne Signatur	Erlaubte Algorithmen serverseitig fest verdrahten
Passwörter in der Payload	Klartext-Leak beim Mitlesen	Nur unkritische Claims speichern
Sehr lange Laufzeit (exp)	Gestohlene Token lange nutzbar	Kurzlebige Access Tokens + Refresh Token
Token im localStorage	Auslesbar bei XSS	HttpOnly-Cookie verwenden, CSP härten

---

Praxisbeispiel: Aufbau eines dekodierten Tokens

Ein reales Token wie eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw... dekodiert sich in drei lesbare Teile:

// Header
{ "alg": "HS256", "typ": "JWT" }
// Payload
{ "sub": "1234", "role": "ROLE_ADMIN", "exp": 1718876400 }
// Signature (binär, nur mit Secret verifizierbar)

Wer dieses Token im Browser-localStorage ablegt, riskiert bei einer Cross-Site-Scripting-Lücke den Diebstahl der Session. Ein gut konfigurierter Security-Header-Verbund mit strenger CSP reduziert dieses Risiko deutlich.

[!TIP] Haben Sie ein verschlüsseltes JWT-Token erhalten und möchten sehen, welche Claims (Benutzerdaten, Ablaufzeiten) sich in der Payload befinden? Nutzen Sie den kostenlosen JWT Decoder auf balou.tools zur sicheren clientseitigen Analyse.