JWT

Das JWT (JSON Web Token, ausgesprochen „dschott") ist ein kompaktes, URL-sicheres Token-Format, das Aussagen über eine Identität und deren Berechtigungen in signierter Form transportiert. Der Empfänger kann das Token rein anhand der Signatur verifizieren — ohne den Aussteller bei jeder Prüfung erneut zu kontaktieren.

JWTs werden häufig als Access Tokens in OAuth 2.0, als ID Tokens in OpenID Connect oder als eigenständiger Sitzungsmechanismus verwendet.

Aufbau

Ein JWT besteht aus drei Base64URL-codierten Teilen, durch Punkte getrennt:

xxxxx.yyyyy.zzzzz
└─┬─┘ └─┬─┘ └─┬─┘
Header Payload Signatur

• Header — beschreibt das Token-Format und das Signaturverfahren (alg).
• Payload — enthält die eigentlichen Aussagen (Claims).
• Signatur — bindet Header und Payload kryptografisch.

Header und Payload sind nur kodiert, nicht verschlüsselt. Ihr Inhalt ist für jeden lesbar, der das Token in die Hand bekommt.

Claims

Im Payload stehen Aussagen über das Subjekt. Der Standard definiert eine Reihe registrierter Claims:

• iss — der Aussteller (Issuer).
• sub — das Subjekt, üblicherweise eine Benutzer-ID.
• aud — der vorgesehene Empfänger (Audience).
• exp — Ablaufzeitpunkt.
• nbf — frühester gültiger Zeitpunkt.
• iat — Ausstellungszeitpunkt.
• jti — eindeutige Token-ID.

Darüber hinaus dürfen anwendungsspezifische Claims (z. B. roles, tenant) ergänzt werden.

Signaturverfahren

Üblich sind zwei Klassen:

• HMAC (z. B. HS256) — symmetrisches Verfahren, Aussteller und Prüfer teilen ein Geheimnis.
• Asymmetrisch (z. B. RS256, ES256) — der Aussteller signiert mit einem privaten Schlüssel, jeder Empfänger prüft mit dem öffentlichen. Standard in verteilten Systemen, da die Prüfer keine Geheimnisse halten müssen.

Das Verfahren none (keine Signatur) ist im Standard zwar definiert, in der Praxis aber gefährlich und sollte abgelehnt werden — historische Schwachstellen entstanden, als Bibliotheken none versehentlich akzeptierten.

Verwendung

Üblicher Ablauf:

1. Der Nutzer authentifiziert sich, der Server stellt ein JWT aus.
2. Der Client legt das Token sicher ab und sendet es bei API-Anfragen mit, meist im Header Authorization: Bearer ….
3. Der Server prüft Signatur, Ablauf und Audience und entscheidet anhand der Claims über den Zugriff.

Vor- und Nachteile

Stärken:

• Selbsterklärend und überprüfbar ohne Rückfrage beim Aussteller.
• Gut geeignet für verteilte Systeme und föderierte Identitäten.
• Standardisiert und breit unterstützt.

Schwächen:

• Widerruf ist schwierig — ein einmal ausgestelltes Token bleibt bis exp gültig. Lösungen: kurze Laufzeiten plus Refresh Tokens, oder eine zusätzliche Sperrliste.
• Nicht für Sitzungs-Cookies in Webanwendungen optimal — klassische, serverseitige Sitzungs-IDs sind oft einfacher und sicherer.
• Inhalte sind sichtbar; sensible Daten gehören nicht in den Payload, sofern keine zusätzliche Verschlüsselung (JWE) eingesetzt wird.