JWT (JSON Web Token)

JSON Web Token (JWT) ist ein offener Standard (RFC 7519) für die sichere Übertragung von Informationen zwischen Parteien als JSON-Objekt. JWTs werden primär für Authentifizierung eingesetzt: Nach dem Login erhält der User ein JWT, das bei jeder Anfrage mitgesendet wird. Der Server validiert das Token ohne Datenbank-Abfrage - ideal für skalierbare, zustandslose APIs.

Ein JWT besteht aus drei Teilen (Base64-kodiert, durch Punkte getrennt): Header (Algorithmus), Payload (Daten wie User-ID, Rollen, Ablaufzeit) und Signature (kryptografische Signatur). Der Server signiert das Token mit einem geheimen Schlüssel. Bei jeder Anfrage wird die Signatur verifiziert - Manipulation ist unmöglich ohne den Schlüssel. Das Payload ist lesbar (nicht verschlüsselt), daher keine sensitiven Daten speichern.

Best Practices: Kurze Ablaufzeiten (15-60 Minuten), Refresh-Tokens für längere Sessions, HTTPS-Only, Tokens im HTTP-Only Cookie (nicht localStorage) gegen XSS. JWTs sind Standard für moderne Web-APIs, Mobile Apps und Microservices-Kommunikation. Bei HEADON.pro implementieren wir JWT-basierte Auth mit Supabase oder eigenen Node.js-Backends.

Die drei Claim-Kategorien im Payload sind genormt: Registered Claims mit reservierten Kurznamen wie iss (Aussteller), sub (Subjekt/User-ID), exp (Ablaufzeitpunkt als Unix-Timestamp), iat (Ausstellungszeit) und aud (Zielgruppe), dazu Public und Private Claims für anwendungsspezifische Daten wie Rollen. Signiert wird entweder symmetrisch mit HS256 (ein geteiltes Geheimnis, ideal wenn Aussteller und Prüfer dasselbe System sind) oder asymmetrisch mit RS256 (der private Schlüssel signiert, der öffentliche verifiziert - nötig, wenn mehrere unabhängige Dienste Tokens prüfen sollen).

Sicherheitskritisch ist die Validierung: Ein Server darf den Algorithmus niemals aus dem Token-Header übernehmen, sonst greift der berüchtigte alg:none-Angriff, bei dem ein Angreifer die Signatur einfach weglässt. Der größte konzeptionelle Nachteil von JWTs ist die fehlende einfache Rückrufbarkeit: Ein einmal ausgestelltes Token bleibt bis zum exp gültig, weshalb man Access-Tokens kurz hält (Minuten) und langlebige Refresh-Tokens serverseitig speichert und bei Verdacht widerrufen kann - idealerweise mit Refresh-Token-Rotation. Fürs Frontend gilt: Tokens gehören in ein HttpOnly-, Secure- und SameSite-Cookie, nicht in localStorage, das per XSS auslesbar ist. Und weil der Payload nur Base64-kodiert, nicht verschlüsselt ist, dürfen dort niemals Passwörter oder sensible Daten stehen. Zur Abgrenzung: JWT ist das Token-Format, OAuth 2.0 das übergeordnete Autorisierungs-Framework, das solche Tokens ausgeben kann.