Ein JWT (JSON Web Token) ist ein offener Standard (RFC 7519) für die kompakte und sichere Uebertragung von Informationen zwischen zwei Parteien als JSON-Objekt. JWTs sind digital signiert und koennen daher verifiziert und vertrauenswuerdig behandelt werden.
JWTs sind der De-facto-Standard für die Token-basierte Authentifizierung in modernen REST-APIs und OAuth-Implementierungen. Im Gegensatz zu klassischen Session-IDs tragen JWTs ihre Informationen selbst, der Server muss keinen Session-Speicher vorhalten (Stateless Authentication).
Aufbau eines JWT
Ein JWT besteht aus drei Teilen, getrennt durch Punkte:
xxxxx.yyyyy.zzzzz
Header.Payload.Signature
Header
Der Header definiert den Token-Typ und den Signatur-Algorithmus:
{
"alg": "RS256",
"typ": "JWT"
}
Payload (Claims)
Der Payload enthaelt die Claims, Aussagen über den Nutzer und Metadaten:
| Claim-Typ | Beispiele | Beschreibung |
|---|---|---|
| Registered | iss, sub, exp, iat | Standardisierte Claims (RFC 7519) |
| Public | name, email, role | Allgemein definierte Claims |
| Private | user_id, org_id | Anwendungsspezifische Claims |
Wichtige Registered Claims:
| Claim | Name | Beschreibung |
|---|---|---|
iss | Issuer | Wer hat das Token ausgestellt? |
sub | Subject | Für wen gilt das Token? (Nutzer-ID) |
exp | Expiration | Wann läuft das Token ab? (Unix-Timestamp) |
iat | Issued At | Wann wurde das Token erstellt? |
aud | Audience | Für welchen Dienst ist das Token bestimmt? |
Signatur
Die Signatur stellt die Integritaet sicher. Sie wird aus Header, Payload und einem geheimen Schlüssel berechnet. Jede Änderung am Payload macht die Signatur ungueltig.
Signatur-Algorithmen
| Algorithmus | Typ | Schlüssel | Empfehlung |
|---|---|---|---|
| HS256 | Symmetrisch | Shared Secret | Einfache Setups |
| RS256 | Asymmetrisch | Public/Private Key | Empfohlen für Production |
| ES256 | Asymmetrisch | Elliptic Curve | Kompakter, modern |
| none | Keine Signatur | Keiner | Niemals verwenden |
Asymmetrische Algorithmen (RS256, ES256) sind für Produktionsumgebungen empfohlen: Der Private Key signiert (bleibt auf dem Server), der Public Key verifiziert (kann verteilt werden).
JWT in der Praxis
Authentifizierungs-Flow
- Nutzer sendet Credentials (Login)
- Server validiert und erstellt JWT mit Nutzerdaten
- JWT wird an den Client zurueckgesendet
- Client sendet JWT bei jedem API-Aufruf im Authorization-Header
- Server validiert die JWT-Signatur und extrahiert die Nutzerdaten
- Kein Session-Lookup noetig, alle Infos stehen im Token
JWT-Speicherung im Client
| Speicherort | Vorteile | Risiken |
|---|---|---|
| HttpOnly Cookie | Nicht per JS auslesbar, automatisch gesendet | CSRF-anfaellig |
| localStorage | Einfache Handhabung | XSS-anfaellig |
| sessionStorage | Wird bei Tab-Schluss geloescht | XSS-anfaellig |
| In-Memory (Variable) | Sicherster Speicherort | Geht bei Page Refresh verloren |
Empfehlung: HttpOnly Cookie mit SameSite-Attribut und CSRF-Schutz, oder In-Memory mit Refresh-Token-Mechanismus.
Refresh-Token-Pattern
Da JWTs eine kurze Lebensdauer haben sollten (15 Minuten bis 1 Stunde), wird ein langlebiger Refresh Token verwendet, um neue Access Tokens zu erhalten:
- Access Token (JWT): Kurzlebig (15-60 Min), wird bei jedem Request gesendet
- Refresh Token: Langlebig (Tage/Wochen), in HttpOnly Cookie, nur für Token-Erneuerung
JWT in Next.js
In Next.js-Projekten werden JWTs häufig mit Auth-Libraries wie NextAuth.js (Auth.js) oder Lucia eingesetzt:
- Server Components: JWT aus dem Cookie lesen und validieren
- API Routes/Server Actions: JWT-Validierung in der Middleware
- Middleware: Zentraler Auth-Check für geschuetzte Routen
- OAuth-Integration: JWTs als Access Tokens von OAuth-Providern
Sicherheits-Best-Practices
Do's
- Kurze Ablaufzeiten (
exp) setzen (15-60 Minuten) - Starke Signatur-Algorithmen verwenden (RS256, ES256)
- Alle Claims validieren (
exp,iss,aud) - Tokens über HTTPS uebertragen
- Sensitive Daten nicht im Payload speichern (ist nur Base64, nicht verschluesselt)
Don'ts
alg: noneniemals akzeptieren- JWTs nicht als Session-Ersatz für klassische Webanwendungen missbrauchen
- Keine schwachen Secrets (min. 256 Bit für HS256)
- Token-Revocation nicht vergessen (Blacklist oder kurze Lebensdauer)
- Keine personenbezogenen Daten im JWT ohne Verschluesselung (JWE)
JWT vs. Session-basierte Authentifizierung
| Aspekt | JWT | Session |
|---|---|---|
| Speicherort | Client | Server |
| Skalierbarkeit | Hoch (stateless) | Mittel (Session Store noetig) |
| Revocation | Schwierig | Einfach (Session loeschen) |
| Datenmenge | Im Token enthalten | Nur Session-ID im Cookie |
| Microservices | Ideal (kein zentraler Store) | Aufwaendig (Shared Store) |
| Komplexitaet | Hoeher | Niedriger |
Für API-zentrierte Architekturen und Microservices sind JWTs die bessere Wahl. Für klassische Server-gerenderte Webanwendungen sind Sessions oft einfacher und sicherer zu handhaben.