Ratgeber · JWT 2026
JWT oder Session-Cookie? Eine ehrliche Abwägung
JWT lohnt sich bei Microservices, Mobile-Clients und API-Gateways. Klassische Sessions bleiben besser für Monolithen mit User-Logout.
Zwei Welten
JWT-basierte Auth und klassische Server-Sessions sind nicht "neu vs alt" - sie sind verschiedene Tools für verschiedene Probleme. Wer pauschal JWT wählt, weil "moderner", übersieht oft, dass Sessions in vielen Fällen die einfachere und sicherere Lösung sind.
Klassische Server-Session - wie sie funktioniert
- User loggt sich ein, Server validiert Credentials
- Server generiert zufällige Session-ID (z.B. 32 byte random)
- Session-ID wird in Datenbank gespeichert mit User-Verknüpfung und Ablaufzeit
- Server sendet Session-ID als httpOnly-Cookie zurück
- Bei jedem Request: Browser sendet Cookie automatisch, Server lookup Session-ID in DB
- Logout: Session-Eintrag aus DB löschen - Token sofort ungültig
JWT-basierte Auth - wie sie funktioniert
- User loggt sich ein, Server validiert Credentials
- Server generiert JWT mit Claims (sub, exp, role etc.), signiert es
- Server sendet JWT an Client (im Body oder als Cookie)
- Client speichert JWT (Cookie, localStorage, Memory) und sendet es bei jedem Request
- Server verifiziert Signatur und Claims - KEINE DB-Lookup nötig
- Logout: Server kann das Token nicht zurücknehmen - es bleibt bis exp gültig
Wo JWT klar gewinnt
- Microservice-Architekturen: Resource-Server kann das Token unabhängig vom Auth-Server verifizieren. Keine zentrale Session-DB als Skalierungs-Engpass.
- Mobile-Apps: einfacheres Handling als Cookies, Token kann im Secure-Storage liegen.
- OAuth-2.0-Setups: hier ist JWT die De-Facto-Sprache zwischen Auth-Provider und Resource-Server.
- Service-to-Service-Auth: kurze Lifetimes, enge Scopes, kein Bedarf für DB-Lookups.
Wo Sessions klar gewinnen
- Sofortiger Logout muss funktionieren: Banking-Apps, Healthcare, Admin-Panels. Bei JWT bleibt der Token bis exp gültig, selbst nach "Logout" - es sei denn, der Server führt eine Blacklist (was den Stateless-Vorteil zerstört).
- Permission-Änderungen sollen sofort durchschlagen: User wird zum Admin upgraded oder degraded - bei JWT erst beim nächsten Token-Refresh sichtbar.
- Monolithische Architekturen: ein einziger Server, Session-DB ohnehin da. Stateless bringt keinen Vorteil.
- Compliance-Requirements, die Audit-Trails über jeden Token-Use erfordern: Sessions in DB sind dafür einfacher.
Direkter Vergleich
| Eigenschaft | Server-Session | JWT |
|---|---|---|
| Stateless? | Nein (DB-Lookup) | Ja (Signatur reicht) |
| Logout-Latenz | Sofort | Bis exp (oder via Blacklist) |
| Mehrere Backends | Brauchen gemeinsame DB | Brauchen nur Public Key |
| Token-Größe (Cookie) | ~32 byte | 500-1500 byte |
| Permission-Updates | Sofort | Beim nächsten Refresh |
| Mobile-Support | Cookies awkward | Native |
| DB-Last bei vielen Requests | Hoch | Null |
| Sicherer Token-Storage im Browser | httpOnly-Cookie automatisch | Erfordert sorgfältige Wahl (siehe Storage-Ratgeber) |
Hybrid-Pattern: Refresh-Token in Cookie + Access-Token in Memory
Das Pattern, das in Production am häufigsten gewinnt, ist hybrid: kurzlebiger Access-Token (JWT, 5-15 min) im JS-Memory + langlebiger Refresh-Token (opake String) im httpOnly-Cookie. Refresh-Token wird gegen DB geprüft (Stateful, kann revoziert werden), Access-Token wird stateless verifiziert.
Vorteile: Sofortiges Logout möglich (Refresh-Token aus DB löschen, neuer Access-Token kann nicht mehr ausgestellt werden), kurze Access-Token-Lifetime begrenzt Schadensfenster, kein DB-Lookup pro API-Call. Siehe Refresh-Token-Pattern.
Daumenregel
Brauche ich mehr als einen Service, der unabhängig deployen will? Habe ich Mobile-Clients? Ist sofortiges Logout NICHT kritisch (Toleranz von 15 min OK)? → JWT.
Habe ich einen Monolithen, ein Web-UI, Compliance-Anforderungen an Sofort-Logout? → Sessions.
Habe ich beides? → Hybrid (Refresh-Token + Access-Token).