Ein JWT (JSON Web Token) ist ein offener Standard (RFC 7519) fuer 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 fuer 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 ueber 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 | Fuer wen gilt das Token? (Nutzer-ID) |
exp | Expiration | Wann laeuft das Token ab? (Unix-Timestamp) |
iat | Issued At | Wann wurde das Token erstellt? |
aud | Audience | Fuer welchen Dienst ist das Token bestimmt? |
Signatur
Die Signatur stellt die Integritaet sicher. Sie wird aus Header, Payload und einem geheimen Schluessel berechnet. Jede Aenderung am Payload macht die Signatur ungueltig.
Signatur-Algorithmen
| Algorithmus | Typ | Schluessel | Empfehlung |
|---|---|---|---|
| HS256 | Symmetrisch | Shared Secret | Einfache Setups |
| RS256 | Asymmetrisch | Public/Private Key | Empfohlen fuer Production |
| ES256 | Asymmetrisch | Elliptic Curve | Kompakter, modern |
| none | Keine Signatur | Keiner | Niemals verwenden |
Asymmetrische Algorithmen (RS256, ES256) sind fuer 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 fuer Token-Erneuerung
JWT in Next.js
In Next.js-Projekten werden JWTs haeufig 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 fuer 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 ueber HTTPS uebertragen
- Sensitive Daten nicht im Payload speichern (ist nur Base64, nicht verschluesselt)
Don'ts
alg: noneniemals akzeptieren- JWTs nicht als Session-Ersatz fuer klassische Webanwendungen missbrauchen
- Keine schwachen Secrets (min. 256 Bit fuer 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 |
Fuer API-zentrierte Architekturen und Microservices sind JWTs die bessere Wahl. Fuer klassische Server-gerenderte Webanwendungen sind Sessions oft einfacher und sicherer zu handhaben.