JWT als Session-Token steht seit Jahren in der Kritik, weil ein einmal ausgestelltes Token bis zum Ablauf gültig bleibt und sich nicht ohne Weiteres zurückziehen lässt. Ein viel beachteter Beitrag auf Hacker News bringt die Debatte mit dem Titel „Stop Using JWTs“ auf den Punkt.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Kommt Ihnen das bekannt vor? Ein Mitarbeiter verlässt das Unternehmen, doch sein Zugang bleibt aktiv, weil das Token noch zwei Stunden läuft. Genau an diesem Punkt setzt die Kritik an.
Das Wichtigste in Kürze
- Kein Widerruf: Ein reines JWT lässt sich vor dem Ablauf kaum sperren, weil der Server es gar nicht kennt.
- Stateless-Falle: Sobald eine Sperrliste nötig wird, ist der angebliche Vorteil der Zustandslosigkeit dahin.
- Bekannte Lücken: alg=none und die RS256/HS256-Verwechslung tauchen bis heute in neuen CVEs auf.
- Gegenposition: Für kurzlebige Transport-Token zwischen Servern bleibt JWT sinnvoll.
Warum ist JWT als Session-Speicher problematisch?
Der fehlende Widerruf wiegt am schwersten. Müssen Sie einen Mitarbeiter aussperren oder ein gestohlenes Token sofort kassieren, fehlt bei einem reinen JWT der Hebel. Der Server prüft nur die Signatur und vertraut dem Inhalt, ohne das Token selbst zu kennen.
Die Stateless-Falle verschärft das Problem. Eine serverseitige Sperrliste schafft zwar Abhilfe, doch genau diese Liste macht aus dem zustandslosen JWT wieder einen zustandsbehafteten Dienst. Damit fällt der wichtigste Grund weg, der überhaupt für JWT sprach. Der Gist-Autor bringt es auf die Formel: Sobald Sie Nutzer verwalten, betreiben Sie ohnehin einen Dienst mit Zustand und brauchen einen Datenspeicher.
Klassische Sitzungen mit sicheren, httpOnly-Cookies wurden für genau diesen Zweck gebaut. Sie liegen serverseitig im Tresor, lassen sich jederzeit löschen und bleiben beim Logout sofort wirksam, statt eine Restlaufzeit abzuwarten.
Welche Sicherheitslücken kehren immer wieder?
Zwei Implementierungsfehler bilden eine eigene Angriffsklasse: alg=none und die RS256/HS256-Verwechslung. Beide entstehen nicht durch Pech, sondern durch nachlässige Voreinstellungen.
Der Klassiker ist die Angabe alg=none. Eine nachlässige Bibliothek akzeptiert dann ein völlig unsigniertes Token als gültig. Selbst wer den Wert „none“ sperrt, übersieht oft Schreibvarianten wie „nOnE“, solange der Vergleich nicht konsequent kleingeschrieben wird.
Subtiler ist die Verwechslung von RS256 und HS256. Bei diesem Muster wählt der Angreifer den Algorithmus selbst und missbraucht den öffentlich verteilten Schlüssel als HMAC-Geheimnis, um sich gültige Token zu basteln. Genau deshalb empfiehlt das OWASP-Projekt, den erlaubten Algorithmus serverseitig fest vorzugeben und ihn nie aus dem Token zu übernehmen. Wie schnell solche Lücken real werden, zeigen die jüngsten Token-Schwachstellen rund um Authenticator-Apps.
Ein Token, das sich nicht zurückziehen lässt, ist kein Feature, sondern eine offene Hintertür auf Zeit. Für Sessions gehört die Kontrolle auf den Server, nicht in den Browser des Nutzers.
— Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Teams im Mittelstand jetzt tun?
Sichere Defaults schlagen jede nachträgliche Reparatur. JWT ist nicht per se schlecht: Für kurzlebige Transport-Token zwischen zwei Servern, etwa beim Single Sign-on, spielt das Format seine Stärke aus. Für die normale Anmeldung in Ihrer Web-App führt der bequemere Weg jedoch ins Risiko.
Setzen Sie serverseitige Sessions mit httpOnly-Cookies als Standard, idealerweise mit einem schnellen Speicher wie Redis. Erzwingen Sie den Signaturalgorithmus fest im Code, statt ihn aus dem Token zu lesen. Halten Sie Token-Laufzeiten kurz und ergänzen Sie eine Sperrliste, falls Sie aus guten Gründen doch bei JWT bleiben. Diese Maßnahmen gehören zu den Cybersecurity-Grundlagen für KMU und zahlen direkt auf eine saubere Absicherung Ihrer Anwendung ein.
