Ein alter, aber hartnäckiger Streit der Webentwicklung kocht gerade wieder hoch: Taugen JSON Web Tokens als Login-Mechanismus? Der vielbeachtete Standpunkt des Entwicklers Sam Schlinkert sagt klar nein. Für das Anmelden von Nutzern seien JWTs das falsche Werkzeug, klassische Cookie-Sessions die bessere Wahl.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Die Debatte trifft einen Nerv, weil unzählige Tutorials JWTs als modernen Standard für Authentifizierung verkaufen. Genau diese Gewohnheit nimmt der Beitrag auseinander.
Das Wichtigste in Kürze
- JWTs sind laut dem Standpunkt nicht dafür gebaut, eine Nutzersitzung im Browser aufrechtzuerhalten.
- Die empfohlene Alternative für Logins sind serverseitige Sitzungen mit ganz normalen Cookies.
- Authentifizierungs-Token gehören nicht in localStorage oder sessionStorage, weil sie dort angreifbar sind.
- Echte stateless-Authentifizierung lässt sich ohne sehr großen Aufwand kaum sicher umsetzen.
Warum sind JWTs für Logins das falsche Werkzeug?
Der zentrale Einwand betrifft den Verwendungszweck. JWTs wurden für den signierten Transport von Daten zwischen Systemen entworfen, nicht für das dauerhafte Anmelden eines Nutzers im Browser. Wer sie dafür einsetzt, kämpft mit Problemen, die Cookie-Sessions gar nicht erst haben, etwa dem sicheren Zurückziehen eines bereits ausgegebenen Tokens.
Ein häufiges Gegenargument lautet, dass selbst Google JWTs nutze. Der Standpunkt entkräftet das: Google verwendet im Browser reguläre Cookie-Sessions und setzt JWTs nur als Transport für Single Sign-on ein, mit den Sicherheitsressourcen eines Großkonzerns im Rücken. Für die meisten Projekte ist dieser Sonderfall keine Vorlage.
Was spricht für klassische Sessions?
Die Alternative ist unspektakulär, und genau das ist der Punkt. Serverseitige Sitzungen mit signierten Cookies erledigen das, wofür JWTs oft zweckentfremdet werden, ohne die Nachteile. Viele Web-Frameworks signieren und verschlüsseln Cookies bereits automatisch, sodass der gleiche Schutz ohne doppelte Signaturprüfung entsteht.
Doppelte Signaturen kosten zudem Rechenzeit, was in Umgebungen mit einem einzigen Verarbeitungsfaden den Hauptablauf blockieren kann. Wer Sitzungen sauber aufsetzt, bekommt einen einfacheren und besser prüfbaren Mechanismus. Eine verwandte Regel betrifft den Speicherort: Anmeldedaten und Token gehören nicht in localStorage, weil sie dort für Skripte im Browser erreichbar sind. Wer Authentifizierung im eigenen Stack neu denkt, findet im Cybersecurity-Grundlagenartikel den passenden Rahmen.
Stateless klingt nach Fortschritt, ist beim Login aber oft nur verlagerte Komplexität. Eine signierte Cookie-Session ist langweilig, gut verstanden und sicher. Langeweile ist in der Sicherheit ein Kompliment.
— Michael Dobler, Herausgeber Dr. Web
Wann ergeben JWTs trotzdem Sinn?
Der Beitrag verteufelt JWTs nicht pauschal. Für den Austausch von Identität zwischen verschiedenen Servern oder Hosts, also für Single Sign-on, liegt der Einsatz im sinnvollen Rahmen. Auch dort verweist der Autor allerdings auf Alternativen wie PASETO, die einige Fallstricke des JWT-Standards vermeiden.Für die alltägliche Frage, wie eine Webanwendung ihre Nutzer eingeloggt hält, bleibt die Empfehlung eindeutig: erst die einfache, bewährte Session prüfen, bevor man zum komplexeren Token greift. Wer seine Toolchain und Sicherheitsbasis ohnehin überprüft, findet weitere Anregungen in unseren Tipps für Webentwickler.
