JWT vs. Session-Tokens

Sessions halten die Wahrheit serverseitig: Ein intransparentes Token von 16–32 Byte indiziert einen Speicher, den Sie kontrollieren, daher ist der Widerruf sofort und günstig. JWTs tragen die Wahrheit im Token selbst – signiert, zustandslos, überall verifizierbar –, aber Widerruf bedeutet, die Gültigkeitsdauer abzuwarten. Verwenden Sie Sessions für Logins in einer einzelnen App; JWTs, wenn viele Dienste Identität ohne gemeinsamen Speicher verifizieren müssen.

Nur lokal

Beide Entwürfe lösen dasselbe Problem: HTTP-Requests kommen ohne Gedächtnis an, also braucht jeder Request etwas, das sagt: „Das ist dieselbe Person, die sich angemeldet hat“. Eine klassische Session gibt dem Client ein intransparentes Token mit – eine zufällige Zeichenkette, die auf serverseitigen Zustand zeigt. Ein JWT (RFC 7519) gibt dem Client den Zustand selbst mit: ein signiertes Bündel von Claims, das der Server ohne Nachschlagen verifiziert. Das eine speichert die Wahrheit auf dem Server; das andere beglaubigt sie und schickt sie mit.

Dieser Unterschied – wo die Wahrheit liegt – pflanzt sich in jede Abwägung hier fort. Ein JWT verifiziert mit einer Signaturprüfung, also kann jeder Dienst, der den Schlüssel hält, einen Request authentifizieren, ohne einen gemeinsamen Speicher; der Preis ist, dass das Token bis zu seinem exp-Claim gültig bleibt, sodass „jetzt abmelden“ und „diesen Nutzer jetzt sperren“ keine natürliche Implementierung haben. Ein Session-Token ist ohne seinen Speicher wertlos, daher ist Widerruf ein Delete – aber jeder verifizierende Dienst muss diesen Speicher erreichen.

Keine Seite gewinnt, und ausgereifte Systeme fahren routinemäßig beides – intransparente Session-Cookies für die App mit Benutzeroberfläche, kurzlebige JWTs zwischen Diensten. Die folgenden Abschnitte vergleichen Widerruf, Speicherung, Größe und Angriffsfläche; der überall verlinkte Decoder lässt Sie echte Tokens untersuchen, ganz ohne Upload.

Bevor Sie einem Token in der Produktion vertrauen, klappen Sie eines mit dem JWT-Decoder auseinander – er dekodiert Header und Payload lokal und fragt nie nach einem Schlüssel.

Für eine Aufschlüsselung Segment für Segment erklärt der Leitfaden zum JWT-Aufbau Header, Payload und Signatur mit echten Beispielen.

Zwei Formen, zwei Philosophien

Eine Server-Session ist ein Zeiger. Das Token – 16 bis 32 zufällige Bytes, meist als Cookie gesetzt – trägt keine Bedeutung; alle Bedeutung lebt im Speicher: Redis, eine Datenbank, sogar der Prozessspeicher. Diese Indirektion ist das Feature. Der Eintrag kann alles halten, alles ändern oder verschwinden, und Clients bemerken nichts davon, denn sie halten nur einen Zeiger.

Ein JWT ist eine Aussage. Drei Base64url-Segmente – Header, Payload, Signatur – tragen die Claims: sub für den Nutzer, iss für den Aussteller, exp für die Gültigkeit, dazu eigene Claims. Die Signatur (HMAC mit geteiltem Geheimnis oder RSA/ECDSA mit Schlüsselpaar) beweist, dass die Aussage unversehrt ist und von einem Schlüssel-Inhaber stammt. Verifizieren braucht kein Nachschlagen; vertrauen braucht nur den Schlüssel.

Widerruf: der Kompromiss, der die meisten Projekte entscheidet

Bei Sessions sind „Abmelden“ und „Nutzer sperren“ Speicheroperationen: Eintrag löschen, und der nächste Request schlägt fehl. Bei JWTs bleibt das Token kryptografisch gültig bis exp, egal was der ausstellende Server inzwischen wünscht – der Sinn von Zustandslosigkeit ist, dass die Verifizierung nie zurückfragt. Die Gegenmaßnahmen sind wohlbekannt und führen alle Zustand wieder ein: kurze Gültigkeit mit Refresh-Token-Rotation, jti-Sperrlisten oder ein Version-Claim, der beim Logout erhöht wird. Jede baut ein Stück des Speichers wieder auf, auf den Sie verzichtet haben.

Ehrlich gefasst: Sessions machen Widerruf gratis, berechnen aber bei jedem Request einen Speicher-Lookup; JWTs machen ihn zur Entwurfsentscheidung, die Sie beim Logout bezahlen. Wenn „überall und sofort abmelden“ eine Anforderung ist, stehen Sessions oder streng verwaltete Rotation in Ihrem weiteren Weg.

Speicherung und Angriffsfläche: Cookies, localStorage, XSS und CSRF

Wo das Token lebt, ist ebenso wichtig wie was es ist. Ein in localStorage abgelegtes JWT ist von jedem Skript auf der Seite lesbar, also exfiltriert eine einzige XSS-Schwachstelle ein Bearer-Credential, das bis zum Ablauf gültig ist – ohne serverseitige Möglichkeit, es zu widerrufen. Ein intransparentes Token in einem HttpOnly-, Secure- und SameSite-Cookie ist für JavaScript unsichtbar, was den Schadenradius von XSS begrenzt; der Preis ist die CSRF-Exposition – der Browser hängt das Cookie automatisch an –, gemildert durch SameSite und CSRF-Tokens.

JWTs können ebenfalls in Cookies fahren (und sollten es oft), mit denselben CSRF-Einschränkungen; ein Authorization-Header umgeht CSRF, bringt das Token aber zurück in JavaScripts Reichweite. Keine Speichervariante ist sicher gegen XSS – nur Varianten, die begrenzen, was ein Angreifer stehlen kann.

Größe – und was ein JWT tatsächlich verrät

Ein typisches Login-JWT misst mit ein paar Claims 800 Byte oder mehr, und jeder Request wiederholt es – während Cookies bei etwa 4 KB pro Domain an ihre Grenze stoßen. Ein intransparentes Session-Token bleibt in jedem Fall 16–32 Byte. Bei Skalierung zeigt sich der Unterschied in Headern, Proxies und Logs.

Der Payload ist Base64url – Kodierung, keine Verschlüsselung –, also kann jeder, der das Token hält, jeden Claim lesen, personenbezogene Daten und Berechtigungen eingeschlossen. JWE existiert für verschlüsselte Tokens und wird fast nie verwendet. Fügen Sie unten ein echtes Token in den Decoder ein: Header und Payload klappen in Ihrem Browser auf, die Signatur wird angezeigt, aber nie verifiziert – Verifizierung bräuchte den geheimen Schlüssel, nach dem das Tool nie fragt.

Aspekt	Server-Session	JWT (RFC 7519)
Wo die Wahrheit liegt	Serverseitiger Speicher	Im signierten Token
Widerruf	Sofort – Eintrag löschen	Bei exp, oder über zusätzlichen Zustand
Token-Größe	16–32 intransparente Bytes	~800 B+ mit typischen Claims
Kosten der Verifizierung	Speicher-Lookup pro Request	Signaturprüfung, kein Lookup
Authentifizierung über mehrere Dienste	Gemeinsamer Session-Speicher nötig	Jeder Dienst, der den Schlüssel hält
Ablauf	Serverseitige TTL, änderbar	exp-Claim, bei Ausstellung fixiert
Browserspeicher	HttpOnly- + SameSite-Cookie	Cookie oder localStorage (XSS-Risiko)

Wann Sie was wählen

Wählen Sie Sessions, wenn eine Anwendung den Login abwickelt: servergerenderte Websites, Admin-Panels, alles, wo sofortiger Logout und Geräteverwaltung einen Redis-Lookup wert sind. Wählen Sie JWTs, wenn die Verifizierung an vielen Stellen passieren muss – Microservices, mobile Apps, dienstübergreifende Services – und ein gemeinsamer Session-Speicher für alle davon der schwerere Preis wäre.

Die Empfehlung kehrt sich sauber um. Sobald Sie eine Sperrliste oder einen Rotation-Dienst bauen, um JWTs widerrufbar zu machen, fragen Sie, ob sich ein Session-Speicher wieder eingeschlichen hat; sobald ein Session-Speicher zum Flaschenhals für ein Dutzend Dienste wird, fragen Sie, ob kurzlebige JWTs zwischen ihnen leichter wären. Hybride – ein intransparentes Cookie für den Browser, JWTs von Dienst zu Dienst – sind kein Kompromiss; sie sind der normale Endzustand.

Häufig gestellte Fragen

Kann ich hier ein JWT dekodieren, ohne es hochzuladen oder irgendwohin zu senden?

Ja. Der Decoder läuft vollständig in Ihrem Browser: Header und Payload sind schlichtes Base64url, sie klappen also lokal auf, ohne dass ein Request den Tab verlässt – die Content-Security-Policy der Website blockiert ausgehende Aufrufe. Die Signatur wird zur Ansicht angezeigt, aber nie verifiziert: Verifizierung bräuchte den Signaturschlüssel, nach dem das Tool nie fragt.

Ist ein JWT verschlüsselt?

Nein. RFC 7519 definiert ein signiertes Token: Der Payload ist Base64url – für jeden lesbar, der ihn hält – und die Signatur beweist nur, wer ihn ausgestellt hat und dass er nicht verändert wurde. Verschlüsselung ist ein eigenes Profil (JWE), das echte Systeme selten nutzen. Behandeln Sie jeden Claim als öffentlich: Bezeichner und Rollen sind unproblematisch; Geheimnisse und personenbezogene Daten nicht.

Wie widerrufe ich ein JWT sofort?

Mit dem Token allein geht das nicht – das ist der Preis der Zustandslosigkeit. Echte Systeme fügen Zustand wieder hinzu: kurze exp-Fenster mit Refresh-Token-Rotation, damit gestohlene Tokens schnell sterben, eine Sperrliste mit dem jti-Claim als Schlüssel oder ein Token-Versions-Claim, der beim Logout erhöht wird. Alle drei sind ein Session-Speicher mit Zusatzschritten.

Sind HttpOnly-Cookies für Tokens sicherer als localStorage?

Gegen XSS: ja. localStorage ist von jedem Skript auf der Seite lesbar, also stiehlt eine einzige Injektion ein Bearer-Token, das bis zum Ablauf gültig ist; ein HttpOnly-Cookie ist für JavaScript unsichtbar, dieselbe Injektion kann es also nicht mitnehmen. Der Preis des Cookies ist CSRF, behandelt mit SameSite und CSRF-Tokens. HttpOnly besiegt XSS nicht – es nimmt das Token nur aus der Beute heraus.

Warum bevorzugen Microservices JWTs gegenüber Sessions?

Weil die Verifizierung lokal wird. Mit RS256 hält jeder Dienst den öffentlichen Schlüssel und validiert Tokens, ohne einen gemeinsamen Session-Speicher aufzurufen; ein neuer Dienst startet mit einem Schlüssel, nicht mit einer Integration. Intransparente Sessions lassen jeden Dienst von der Verfügbarkeit eines einzigen Speichers abhängen. Diese Unabhängigkeit kauft die Zustandslosigkeit – der Widerruf ist die Rechnung.

Wie groß kann ein JWT werden, bevor es zum Problem wird?

Achten Sie zuerst auf Cookies: Browser begrenzen sie auf etwa 4 KB pro Domain, und ein claims-reiches JWT kann sich dem nähern und Requests direkt zum Scheitern bringen. Auch unter der Grenze reitet ein ~800-Byte-Token auf jedem Request, während ein intransparentes Session-Token in jedem Fall 16–32 Byte bleibt. Halten Sie die Claims schlank: Identität und Ablauf, keine Profildaten.

Wo kann ich die hier zitierten Standards nachlesen?

RFC 7519 — JSON-Web-Token (JWT)

ToolsByUs-Team · Wie wir unsere Tools prüfen