Die Frage „JWT oder Session?“ wird oft wie eine Wahl zwischen modern und veraltet behandelt. Tatsächlich lösen beide Modelle dieselbe Grundaufgabe mit unterschiedlicher Zustandsverteilung. Eine serverseitige Session hält die maßgeblichen Daten im Backend und gibt dem Client eine undurchsichtige ID. Ein JWT trägt verifizierbare Claims zum Client und kann an mehreren Stellen ohne zentralen Lookup geprüft werden. Keine Variante ist automatisch skalierbarer oder sicherer.

Eine Session macht den Server zur aktuellen Wahrheit

Nach dem Login erzeugt der Server einen zufälligen Session-Identifier und speichert Benutzerbezug, Ablauf und weitere Zustände in Datenbank oder Cache. Der Browser sendet die ID meist in einem HttpOnly-Cookie. Bei jedem Request lädt der Server die aktuelle Session.

Logout, Sperrung und Rechteänderungen lassen sich unmittelbar umsetzen, weil der Datensatz geändert oder gelöscht wird. Dafür braucht jeder Request Zugriff auf den Session-Store, der hochverfügbar und ausreichend schnell sein muss.

JWT verschiebt einen Teil des Zustands in das Token

Ein Dienst kann Signatur und Claims lokal prüfen, ohne für jede Anfrage den Aussteller zu kontaktieren. Das ist nützlich zwischen unabhängigen APIs oder in föderierten Systemen. Die Information bleibt jedoch bis zum Ablauf eine Momentaufnahme.

Widerruf, Refresh Tokens, Schlüssel und Benutzerstatus erzeugen oft weiterhin serverseitigen Zustand. JWT beseitigt nicht automatisch Datenbanken, sondern kann einen häufigen Auth-Lookup vermeiden oder Vertrauensgrenzen zwischen Diensten standardisieren.

Für klassische Webanwendungen sind Sessions oft einfacher

Wenn Browser und Backend demselben Produkt gehören, bietet ein sicher konfigurierter Session-Cookie einen gut verstandenen Weg. Tokens müssen nicht für JavaScript sichtbar sein, Logout ist direkt, und Rollen können bei jedem Request aktuell geladen werden.

Horizontale Skalierung ist mit einem gemeinsamen Redis- oder Datenbank-Store möglich. Alternativ kann ein Load Balancer Sessions an einen Host binden, wobei ein zentraler Store meist robuster bei Ausfällen und Deployments ist.

Mehrere APIs können von signierten Access Tokens profitieren

In einer Service-Landschaft kann ein Identity Provider ein kurzlebiges Token für eine bestimmte Audience ausstellen. Jeder Zielservice prüft es mit dem öffentlichen Schlüssel. Der private Signaturschlüssel muss nicht an alle Dienste verteilt werden.

Das reduziert Kopplung an einen zentralen Session-Lookup, verlangt aber konsistente Bibliotheken, Claim-Semantik und Schlüsselrotation. Ein Service darf nicht jedes Token akzeptieren, nur weil es vom gemeinsamen Provider stammt.

Mobile und externe Clients verändern die Randbedingungen

Native Apps arbeiten nicht exakt wie Browser und können OAuth-basierte Access- und Refresh-Tokens sicherer in Betriebssystemspeichern halten. Öffentliche API-Clients brauchen standardisierte Delegation statt einen Website-Cookie. Für solche Szenarien passt ein Tokenprotokoll häufig besser.

Ein JWT ist dabei nur ein mögliches Access-Token-Format. OAuth schreibt nicht vor, dass Access Tokens lesbare JWTs sein müssen. Undurchsichtige Tokens mit Introspection können zentralen Widerruf und geringere Datenexposition bieten.

Widerruf ist eine Produktanforderung

Muss ein Administrator Zugriff sofort beenden, ist eine Session leicht zu löschen. Bei selbständig verifizierten JWTs bleibt das Token bis zum Ablauf gültig, sofern Dienste keine Revocation oder aktuelle Sessionversion prüfen. Kurze Laufzeiten begrenzen, aber eliminieren die Verzögerung nicht.

Die gewünschte Reaktionszeit sollte vor der Formatwahl feststehen. Ein System für Banking hat andere Anforderungen als ein kurzlebiger Read-only-Datenaustausch.

Cookies und JWT sind keine Gegensätze

Ein JWT kann in einem Cookie transportiert werden, und eine Session-ID kann in einem Authorization-Header stehen. Cookie versus Header beschreibt den Transport; JWT versus undurchsichtige ID beschreibt den Inhalt. Werden diese Achsen vermischt, entstehen pauschale Empfehlungen ohne Bedrohungsmodell.

Browsercookies brauchen Secure, HttpOnly, SameSite und passende Domain- und Path-Grenzen. Header-Tokens, die JavaScript verwaltet, sind bei XSS auslesbar. Jede Kombination hat andere CSRF- und Diebstahleigenschaften.

Token-Größe wirkt sich auf jeden Request aus

Eine kurze Session-ID verursacht wenig Header-Overhead. JWTs können durch Claims, Signaturen und Zertifikatsinformationen mehrere Kilobyte erreichen und bei jedem API-Aufruf übertragen werden. Große Cookies stoßen zusätzlich an Browser- und Proxygrenzen.

Claims sollten deshalb minimal sein. Ein Token ist kein Ersatz für ein Benutzerprofil. Daten, die der Service nicht für die unmittelbare Entscheidung benötigt, gehören in eine andere Schnittstelle.

Sessions erleichtern eine Geräteübersicht

Viele Produkte zeigen aktive Geräte, letzte Nutzung und einen Button zum Abmelden einzelner Sitzungen. Ein serverseitiger Sessiondatensatz bildet dieses Modell direkt ab. Bei JWTs braucht man meist trotzdem Refresh-Session-Datensätze, um dieselbe Funktion bereitzustellen.

Das ist kein Argument gegen JWT, sondern gegen die Annahme vollständiger Zustandslosigkeit. Benutzerfunktionen bestimmen, welche Daten dauerhaft verwaltet werden müssen.

Ausfallverhalten unterscheidet sich

Fällt der Session-Store aus, können Requests nicht authentifiziert werden. Lokal verifizierte JWTs funktionieren während eines Identity-Provider-Ausfalls möglicherweise bis zum Ablauf weiter. Das erhöht Verfügbarkeit, kann aber eine Sperrung oder Incident Response verzögern.

Key-Set-Caches, Clock-Synchronisierung und ablaufende Tokens werden damit Teil des Betriebs. Jede Architektur tauscht einen zentralen Lookup gegen andere Abhängigkeiten, nicht gegen völlige Unabhängigkeit.

Ein Hybrid ist häufig die pragmatische Lösung

Ein Browser kann eine serverseitige Sitzung beim Backend-for-Frontend besitzen. Dieses Backend hält OAuth-Tokens und ruft interne APIs auf. Der Browser erhält keine auslesbaren Access Tokens, während Dienste weiterhin standardisierte Token verwenden.

Auch undurchsichtige Access Tokens mit Introspection verbinden zentrale Kontrolle mit einer einheitlichen API. Architektur muss nicht dogmatisch nur ein Format im gesamten System einsetzen.

Die Wahl folgt konkreten Anforderungen

Sessions passen gut zu eng gekoppelten Webanwendungen, sofortigem Widerruf und häufig wechselndem Benutzerzustand. JWTs passen gut zu klaren Dienstgrenzen, mehreren unabhängigen Verifiern und kurzlebigen, zielgerichteten Claims. Externe Clients benötigen meist ein vollständiges OAuth- oder OpenID-Connect-Protokoll, nicht selbst erfundene Login-Tokens.

Die belastbare Entscheidung dokumentiert Speicherort, Transport, CSRF- und XSS-Schutz, Laufzeiten, Rotation, Logout und Ausfallverhalten. Erst diese Eigenschaften machen ein Authentifizierungsmodell sicher; die Zeichenfolge allein tut es nicht.