JSON Web Token (JWT): Authentifizierung und Sicherheitsleitfaden

Was ist JWT?

JWT (JSON Web Token) ist ein kompaktes, URL-sicheres Token-Format, definiert in RFC 7519, für sicheren Informationsaustausch zwischen Parteien.

JWT besteht aus drei Teilen: Header, Payload und Signature. Diese drei Teile werden durch Punkte (.) getrennt: xxxxx.yyyyy.zzzzz

Bietet zustandslose Authentifizierung. Statt Sitzungsdaten in einer Datenbank zu speichern, sendet der Server den Token an den Client. Der Client sendet den Token mit jeder Anfrage.

Anwendungsfälle: API-Authentifizierung, SSO (Single Sign-On), Authentifizierung zwischen Mikroservices, Autorisierung mobiler Apps.

JWT-Struktur

Header: Enthält Token-Typ (JWT) und Signaturalgorithmus (HS256, RS256, ES256). Base64URL-kodiert.

Payload: Enthält Claims. Registered Claims (iss, sub, aud, exp, nbf, iat, jti), Public Claims und Private Claims. Base64URL-kodiert.

Signature: Der Base64URL-kodierte Header und Payload werden mit einem Punkt verbunden und mit einem geheimen Schlüssel signiert. HS256 verwendet HMAC-SHA256, RS256 verwendet RSA-SHA256.

Beispiel: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT-Nutzungsfluss

1. Benutzer sendet eine Anfrage an den Login-Endpoint mit Benutzername und Passwort.

2. Server verifiziert Anmeldedaten und erstellt JWT. Token wird im Response-Body oder Cookie zurückgegeben.

3. Client speichert den Token in localStorage oder httpOnly-Cookie.

4. Bei nachfolgenden Anfragen sendet der Client JWT als Bearer-Token im Authorization-Header: Authorization: Bearer <token>

5. Server validiert den Token (Signatur- und Ablaufprüfung). Wenn gültig, wird die Anfrage verarbeitet; wenn ungültig, wird 401 Unauthorized zurückgegeben.

Sicherheitsrisiken

Token-Diebstahl: Token in localStorage kann über XSS-Angriff gestohlen werden. httpOnly-Cookie verwenden, um XSS-Risiko zu reduzieren.

Token-Lebensdauer: Kurzlebiger Access-Token (15-30 Min) + langlebiger Refresh-Token (7-30 Tage). Refresh-Token bei jeder Nutzung rotieren.

Algorithmus-Verwirrung: 'none'-Algorithmus oder RS256→HS256-Wechsel. Algorithmus serverseitig als Konstante setzen, nicht aus Token übernehmen.

Sensible Daten: JWT-Payload ist Base64-kodiert, nicht verschlüsselt. Keine sensiblen Daten (Passwort, Kreditkarte) in Payload aufnehmen.

Token-Größe: JWT ist größer als Session-Cookie. Wird mit jeder Anfrage gesendet. Payload minimal halten.

Best Practices

Kurzlebige Token: Access-Token 15-30 Minuten, Refresh-Token 7-30 Tage. Abgelaufene Token werden automatisch ungültig.

httpOnly + Secure + SameSite Cookie: Token in httpOnly-Cookie speichern. JavaScript kann nicht zugreifen (XSS-Schutz). Secure (nur HTTPS). SameSite (CSRF-Schutz).

Token-Rotation: Refresh-Token wird bei jeder Nutzung erneuert. Alter Refresh-Token wird ungültig. Begrenzt Angreifer-Zugriff bei Token-Diebstahl.

Blacklist/Revocation: Blacklist verwenden, um Token zu widerrufen. Revoked Token in Redis speichern. Für Logout und Sicherheitsvorfälle verwenden.

Algorithmus: RS256 (asymmetrisch) für Produktion empfohlen. Mit Private Key signieren, mit Public Key verifizieren. HS256 (symmetrisch) nur für einzelnen Service.

Validierung: Signatur, Issuer (iss), Audience (aud), Ablauf (exp) bei jeder Anfrage prüfen. Alle Prüfungen müssen bestanden sein, bevor Token vertraut wird.

JWT vs. Session-basierte Authentifizierung

JWT: Zustandslos, einfache horizontale Skalierung, ideal für Mikroservices, große Token-Größe, schwer zu widerrufen.

Session: Zustandsbehaftet, erfordert serverseitige Speicherung, benötigt Sticky Session oder Shared Store für horizontale Skalierung, kleine Token-Größe, einfach zu widerrufen.

Auswahlkriterien: Mikroservice-Architektur → JWT. Monolithische Anwendung → Session. Mobile App → JWT. Hohe Sicherheitsanforderung → Session + JWT Hybrid.

Hybrid-Ansatz: Kurzlebiger JWT (Access-Token) + Session-Store (Refresh-Token). Kombiniert Vorteile beider Ansätze.