Wer heute APIs entwickelt oder Authentifizierungssysteme aufbaut, kommt an JWT kaum vorbei. JSON Web Tokens gelten als modern, flexibel und zukunftssicher. Doch je tiefer man in Entwickler-Communities eintaucht, desto häufiger stößt man auf warnende Stimmen. Manche gehen sogar so weit zu sagen: "Verwenden Sie JWT niemals für Benutzer-Logins." Was steckt hinter dieser Warnung?

Was ist JWT eigentlich?

Stellen Sie sich JWT wie einen Personalausweis vor, der alle wichtigen Informationen enthält und digital signiert ist. Ein JWT-Token besteht aus drei Teilen, die durch Punkte getrennt sind: Header, Payload und Signatur.

Der Header enthält Informationen darüber, welcher Algorithmus zur Verschlüsselung verwendet wurde. Im Payload stehen die eigentlichen Daten, etwa die Benutzer-ID oder Rollen. Die Signatur stellt sicher, dass niemand den Token manipuliert hat – ähnlich wie ein Hologramm auf einem echten Ausweis.

Wie funktioniert die JWT-Authentifizierung?

Wenn sich ein Benutzer anmeldet, erhält er vom Server einen JWT-Token. Diesen Token schickt der Client bei jeder Anfrage mit, meist im Authorization-Header. Der Server kann den Token überprüfen und weiß sofort, wer da anfrägt – ohne in einer Datenbank nachschauen zu müssen. Das nennt man "stateless", also zustandslos.

Klingt praktisch, oder? Genau hier beginnen aber auch die Probleme.

Problem 1: Token-Widerruf ist ein Alptraum

Stellen Sie sich vor, Sie haben einem Freund einen Schlüssel zu Ihrer Wohnung gegeben, der sieben Tage lang gültig ist. Am zweiten Tag merken Sie: Der Freund ist nicht mehr vertrauenswürdig. Bei einem normalen Schloss können Sie einfach das Schloss austauschen. Bei JWT ist das nicht so einfach.

Warum ist Ausloggen so schwierig?

Ein Benutzer meldet sich an und erhält einen Token, der sieben Tage gültig ist. Am zweiten Tag ändert er sein Passwort oder Sie möchten ihn aus Sicherheitsgründen ausloggen. Das Problem: Der Token ist immer noch gültig! Er funktioniert weiter, bis er von selbst abläuft.

Bei klassischen Server-Sessions löschen Sie einfach den Eintrag aus der Datenbank – fertig. Der Benutzer ist sofort ausgeloggt. Bei JWT müssen Sie eine sogenannte Blacklist führen, eine Liste ungültiger Tokens. Und damit haben Sie die Zustandslosigkeit bereits aufgegeben.

Besonders kritisch für sensible Anwendungen

Für Banking-Apps, Gesundheitsportale oder andere sicherheitskritische Anwendungen ist das ein ernstes Problem. Ein gestohlener Token kann bis zu seinem Ablaufdatum missbraucht werden – egal ob Sie davon erfahren oder nicht.

Problem 2: JWT-Tokens können sehr groß werden

Eine Session-ID ist typischerweise so kurz wie ein Autokennzeichen: "asb123xyz". Ein JWT-Token hingegen gleicht eher einem mehrseitigen Dokument. Besonders wenn Sie viele Informationen wie Benutzerrollen, Berechtigungen oder Metadaten hineinstecken, kann ein Token hunderte Zeichen lang werden.

Die versteckten Kosten großer Tokens

Denken Sie an einen Briefträger, der jeden Tag dieselbe Route geht. Bei Sessions trägt er nur einen kleinen Zettel mit einer Referenznummer. Bei JWT muss er jedes Mal ein komplettes Dossier mit sich führen. Das bedeutet:

• Jede Anfrage wird durch den langen Token aufgebläht
• Cookies werden größer als nötig
• Bei Millionen von Anfragen summiert sich der zusätzliche Datenverkehr erheblich

Für große Systeme mit vielen Benutzern wird dieser Overhead schnell zu einem echten Kostenfaktor.

Problem 3: Starre Ablaufzeiten

Bei klassischen Sessions können Sie die Gültigkeitsdauer jederzeit auf der Serverseite anpassen – wie bei einer Parkuhr, die Sie beliebig verlängern können. Bei JWT ist die Ablaufzeit (exp) fest im Token eingebacken, wie bei einem Fahrschein mit aufgedrucktem Datum.

Der Balanceakt zwischen Sicherheit und Komfort

Daraus ergeben sich mehrere Dilemmata:

• Setzen Sie eine lange Gültigkeitsdauer, steigt das Risiko bei Diebstahl
• Wählen Sie eine kurze Gültigkeitsdauer, nerven Sie Ihre Benutzer mit ständigen Neuanmeldungen
• Sie können eine Session nicht einfach verlängern – Sie müssen einen neuen Token ausstellen

Die Lösung? Refresh-Tokens. Aber damit wird Ihr System plötzlich deutlich komplexer als eine einfache Session-Verwaltung.

Problem 4: JWT wird oft falsch eingesetzt

JWT ist wie ein Schweizer Taschenmesser – für bestimmte Aufgaben perfekt, aber nicht für alles. Ursprünglich wurde JWT für die Autorisierung zwischen verschiedenen Systemen entwickelt, nicht für Benutzer-Sessions.

Wo JWT wirklich glänzt

Stellen Sie sich vor, Sie haben einen Themenpark mit verschiedenen Attraktionen. Service A ist der Eingang, wo Sie Ihr Ticket (JWT) bekommen. Service B, C und D sind die einzelnen Attraktionen. Diese können Ihr Ticket überprüfen, ohne jedes Mal beim Eingang nachfragen zu müssen. Das ist effizient.

Wo JWT übertrieben ist

Viele Entwickler ersetzen aber eine einfache Session-ID durch JWT, obwohl sie nur eine einzige Anwendung haben. Das ist wie ein Schweizer Taschenmesser zu benutzen, wenn Sie nur einen Schraubenzieher brauchen. Die zusätzliche Komplexität bringt keinen echten Vorteil.

Problem 5: Sicherheitslücken durch Fehlbedienung

JWT hat eine Geschichte gefährlicher Fehler, die durch falsche Handhabung entstehen. Es ist wie ein scharfes Küchenmesser: In geübten Händen kein Problem, für Anfänger potenziell gefährlich.

Häufige Sicherheitsfallen

Entwickler haben in der Vergangenheit folgende Fehler gemacht:

• Versehentliches Verwenden des "none"-Algorithmus, wodurch Tokens gar nicht mehr signiert waren
• Schwache Geheimnisse für die Signatur, die leicht zu erraten waren
• Fehlende Validierung des Algorithmus-Feldes
• Speichern sensibler Daten im Payload – der ist nur kodiert, nicht verschlüsselt!

Der letzte Punkt ist besonders tückisch: Jeder kann einen JWT-Token dekodieren und die Daten darin lesen. Es ist wie ein Brief in einem durchsichtigen Umschlag.

Problem 6: Stateless führt oft zu mehr Komplexität

Das Hauptverkaufsargument für JWT ist die Zustandslosigkeit. In der Praxis enden die meisten Teams aber damit, doch wieder Zustand zu verwalten – nur komplizierter als vorher.

Der versteckte Zustand

Denken Sie an ein "zustandsloses" System wie an einen Laden ohne Kassenbereich. Klingt modern und effizient. Doch dann merken Sie:

• Sie wollen Kunden ausschließen können → Sie brauchen eine Blacklist in der Datenbank
• Sie möchten Einkäufe verfolgen → Sie speichern Token-IDs
• Sie wollen Tokens aktualisieren → Sie speichern Refresh-Tokens in der Datenbank

Am Ende haben Sie Session-Management neu erfunden, nur mit mehr beweglichen Teilen und höherer Komplexität.

Wann macht JWT trotzdem Sinn?

Trotz aller Kritik hat JWT seine Daseinsberechtigung. Es gibt Szenarien, in denen JWT die richtige Wahl ist:

Microservices-Architekturen

Wenn Sie viele verschiedene Services haben, die miteinander kommunizieren, macht JWT Sinn. Jeder Service kann den Token selbst validieren, ohne eine zentrale Datenbank abfragen zu müssen. Das ist wie ein Netzwerk von Filialen, die einen Firmenausweis aktualisieren können, ohne die Zentrale zu kontaktieren.

Massive Skalierung

Bei extrem hohen Anfragezahlen, wo jeder Datenbank-Lookup zählt, kann JWT tatsächlich Vorteile bringen. Aber seien wir ehrlich: Die wenigsten Anwendungen haben dieses Skalierungsproblem.

Einmalige Zugriffe

Für temporäre Links wie Passwort-Zurücksetzen, E-Mail-Verifikationen oder signierte URLs ist JWT ideal. Diese Anwendungsfälle sind zeitlich begrenzt und benötigen keine Widerrufsfunktion.

Ein praktisches Beispiel aus dem Alltag

Stellen Sie sich vor, Sie bauen einen Online-Shop. Benutzer sollen sich anmelden, Produkte durchstöbern, in den Warenkorb legen und bestellen können.

Mit klassischen Sessions

• Benutzer meldet sich an → Session-ID wird in Redis oder Datenbank gespeichert
• Benutzer meldet sich ab → Session wird gelöscht. Fertig.
• Sie können einfach alle Sessions eines Benutzers tracken
• Bei verdächtigen Aktivitäten können Sie sofort eingreifen

Mit JWT

• Benutzer meldet sich an → erhält Token gültig für sieben Tage
• Benutzer meldet sich ab → Token funktioniert trotzdem weiter (ohne Blacklist)
• Wird der Token gestohlen, kann der Angreifer bis zum Ablauf einkaufen
• Sie brauchen Refresh-Tokens, Blacklists und zusätzliche Logik

Welche Variante klingt einfacher und sicherer?

Fazit: JWT ist kein Allheilmittel

JWT ist nicht böse oder grundsätzlich falsch. Das Problem liegt in der übertriebenen Anwendung und dem Hype, der darum entstanden ist. Viele Entwickler greifen zu JWT, weil es modern klingt, nicht weil es das richtige Werkzeug für ihre Aufgabe ist.

Die Hauptprobleme im Überblick:

• Token-Widerruf ist aufwendig und oft nicht vollständig möglich
• Starre Ablaufzeiten führen zu Kompromissen bei Sicherheit oder Komfort
• Große Tokens erhöhen den Datenverkehr unnötig
• Häufige Fehlkonfigurationen öffnen Sicherheitslücken
• Am Ende entsteht oft mehr Komplexität als bei klassischen Sessions

Für Microservices oder spezielle Anwendungsfälle mit hoher Skalierung kann JWT die richtige Wahl sein. Aber für eine normale Webanwendung, wo Benutzer sich an- und abmelden, sind klassische Sessions meist die einfachere, sicherere und wartungsfreundlichere Lösung.

Denken Sie immer daran: Technologie sollte Probleme lösen, nicht neue schaffen. Bevor Sie JWT einsetzen, fragen Sie sich ehrlich: Brauche ich wirklich die Zustandslosigkeit? Oder kompliziere ich mein System nur unnötig?

Häufig gestellte Fragen (FAQ)

Ist JWT grundsätzlich unsicher?

Nein, JWT selbst ist nicht unsicher. Die Probleme entstehen durch falsche Anwendung und fehlende Vorsichtsmaßnahmen. JWT wurde ursprünglich für andere Zwecke entwickelt als die reine Benutzerauthentifizierung.

Wenn Sie JWT richtig konfigurieren, starke Secrets verwenden und die Algorithmen korrekt validieren, kann es sicher sein. Das größere Problem ist, dass JWT für Standard-Login-Szenarien oft mehr Komplexität und Risiken mit sich bringt als klassische Session-basierte Ansätze, ohne dafür echte Vorteile zu bieten.

Kann ich JWT und Sessions kombinieren?

Ja, das ist möglich und wird manchmal praktiziert. Sie können JWT für die Kommunikation zwischen verschiedenen Services verwenden und gleichzeitig klassische Sessions für die Benutzeranmeldung auf der Hauptanwendung.

Allerdings erhöht dies die Komplexität Ihres Systems. Eine typische Hybrid-Lösung wäre: Sessions mit Session-IDs für die primäre Benutzerauthentifizierung und JWT-Tokens für API-Zugriffe oder Kommunikation zwischen Microservices. So nutzen Sie die Stärken beider Ansätze.

Warum sind Refresh-Tokens bei JWT notwendig?

Refresh-Tokens sind ein Workaround für das Problem der starren Ablaufzeiten. Da Sie JWT-Tokens nicht verlängern können, geben Sie dem Benutzer zwei Tokens: einen kurzlebigen Access-Token (z.B. 15 Minuten) und einen längerlebigen Refresh-Token (z.B. 7 Tage).

Wenn der Access-Token abläuft, kann der Client mit dem Refresh-Token einen neuen Access-Token anfordern. Das erhöht zwar die Sicherheit, macht das System aber auch komplexer. Ironischerweise müssen Sie den Refresh-Token oft in einer Datenbank speichern – womit die Zustandslosigkeit von JWT teilweise aufgehoben wird.