JWT vs Session-Authentifizierung

Im Allgemeinen ist der erste Schritt bei der Verwendung einer Anwendung die Authentifizierung, bei der der Endbenutzer seine Identitätsnachweise bereitstellt, um sich erfolgreich anzumelden. Nach diesem Schritt weiß das Identitätssystem (d.h. Identitätsanbieter, Auth-Server usw.), wer der Benutzer ist und auf welche Ressourcen er Zugriff hat.

Da HTTP von Natur aus zustandslos ist, ist jede Anfrage in einer Sitzung unabhängig und ruft keine Informationen von vorherigen auf. Benutzer für jede Aktion erneut zu authentifizieren, ist mühsam und beeinträchtigt die Benutzererfahrung.

Lassen Sie uns sitzungsbasierte Authentifizierung und JWT (JSON Web Tokens)-Authentifizierung einführen, zwei beliebte Methoden zur Aufrechterhaltung des Authentifizierungsstatus. Jede hat einzigartige Vorteile und Kompromisse, und die Wahl zwischen ihnen hängt von den spezifischen Bedürfnissen Ihrer Anwendung ab. Wenn du zwischen den beiden entscheiden musst, ist dieser Leitfaden hier, um zu helfen.

Was ist sitzungsbasierte Authentifizierung?#

Sitzungsbasierte Authentifizierung verlässt sich auf den Server, um einen Datensatz über den Authentifizierungsstatus des Benutzers zu führen. Durch Erstellen und Verwalten von Sitzungen ermöglicht der Server den Benutzern, eingeloggt zu bleiben und weiter mit einer Anwendung zu interagieren, ohne mit jeder Anfrage die Anmeldeinformationen erneut eingeben zu müssen.

Wie funktioniert sitzungsbasierte Authentifizierung?#

Sitzungserstellung

1. Ein Benutzer authentifiziert sich und gibt einige Anmeldeinformationen an (z.B. E-Mail und Passwort).
2. Wenn die Anmeldeinformationen gültig sind, erstellt der Server einen dauerhaften Datensatz, der diese Sitzung darstellt. Die Sitzung enthält Informationen wie eine zufällige Zeichenkette, Benutzerkennung, Sitzungsstartzeit, Sitzungsablaufzeit usw. 
3. Die SessionID wird in der Datenbank gespeichert und als Cookie an den Client des Benutzers zurückgesendet.

Sitzungsvalidierung

1. Der Prozess kann vom Benutzer manuell ausgelöst werden (z.B. durch Klicken auf einen Tab, Aktualisieren einer Seite) oder automatisch vom Client (z.B. während des anfänglichen Seitenaufbaus oder über API-Aufrufe mit einer SessionID).
2. Jeder nachfolgende Aufruf sendet eine HTTP-Anfrage vom Client, die das Sitzungscookie an den Server enthält.
3. Der Server validiert die SessionID, indem er die auf dem Server gespeicherten Sitzungsdaten konsultiert.
4. Wenn sie gültig ist, verarbeitet der Server die Anfrage und autorisiert den Benutzer.

Wie widerruft man eine Sitzung?#

Sitzungen können in Echtzeit ungültig gemacht werden, was in Situationen nützlich ist, in denen schneller Zugriffsentzug erforderlich ist.

• Benutzer loggt sich manuell aus: Der Server löscht den Sitzungsdatensatz und meldet den Benutzer effektiv ab.
• Admins zwingen Benutzerabmeldung: Admins oder Systeme können spezifische Sitzungen beenden, indem sie sie aus der Datenbank löschen. Beispielsweise während eines Sicherheitsverstoßes.
• Sitzungsexpiration: Sitzungen können nach einer festgelegten Inaktivitätsdauer oder einem festen Zeitlimit automatisch ablaufen.

Vorteile der sitzungsbasierten Authentifizierung#

• Einfach und zuverlässig: Der Sitzungsdatensatz bietet eine klare, zentrale Quelle, die ein hohes Maß an Vertrauen ermöglicht und die Autorisierungsentscheidungen zuverlässiger macht.
• Echtzeit-Widerruf: Durch Löschen oder Ungültigmachen des Sitzungsdatensatzes kann der Zugriff eines Benutzers schnell widerrufen werden.

Nachteile der sitzungsbasierten Authentifizierung#

• Latenz im verteilten System: Das Aufrechterhalten von Sitzungsdaten über mehrere Server hinweg erfordert immer das Synchronisieren eines Sitzungsstores. Dies führt zu zusätzlicher Latenz, da der Server den Sitzungsstore jedes Mal überprüfen muss, wenn eine Anfrage gestellt wird.
• Hoher Ressourcenverbrauch: Jede Sitzung beansprucht Serverressourcen, was die Leistung beeinträchtigt, wenn die Benutzerbasis skaliert.
• Sicherheitsrisiko: Sitzungsentführung (durch gestohlene Sitzungscookies) kann unbefugten Zugriff auf Benutzerkonten ermöglichen.
• Eingeschränkte Nutzung für APIs: Sitzungsbasierte Authentifizierung ist nicht ideal für mobile Apps. Sie speichert Sitzungsdaten auf dem Server, was bei vielen Benutzern die Belastung und Komplexität erhöhen kann. Außerdem verwendet sie Cookies, die auf mobilen Geräten schwerer zu handhaben sind.

Was ist JWT-Authentifizierung?#

JSON Web Tokens (JWTs) verfolgen einen anderen Ansatz, indem sie alle relevanten Benutzerinformationen direkt in ein Token einbetten und ein JSON-Objekt verwenden. Im Gegensatz zu sitzungsbasierten Methoden sind JWTs zustandslos, was bedeutet, dass der Server keine Authentifizierungsdatensätze verwaltet.

Wie funktioniert JWT-Authentifizierung?#

Ein JWT besteht aus drei Teilen: einem Header, Payload und Signatur.

• Der Header enthält den Signaturalgorithmus (z.B. HS256) und den Typ des Tokens (JWT).
• Der Payload enthält zentrale Ansprüche, wie die Identität des Benutzers, Benutzerrolle und Ablaufzeit.
• Die Signatur verwendet einen Schlüssel, um den Header und das Payload zu signieren, was die Überprüfung ermöglicht, ob die Signatur manipuliert wurde.

JWT-Ausstellung

1. Der Client sendet Benutzeranmeldeinformationen an den Authentifizierungsserver (Ein universeller Identitätsanbieter ist besonders vorteilhaft für die Verwaltung des Zugriffs über mehrere Domains hinweg.)
2. Nach erfolgreicher Authentifizierung generiert der Server ein JWT, das Header, Payload und Signatur enthält.
3. Der AuthServer sendet das ausgegebene Token an den Client. Der Client speichert das JWT (z.B. in Cookies, localStorage oder sessionStorage).

Sitzungsbasierte Workflows folgen einem ähnlichen Prozess. Nach der Authentifizierung werden jedoch die Benutzerinformationen innerhalb einer Sitzung auf dem Server gespeichert, während JWTs auf Token angewiesen sind, die an den Client zur Speicherung und anschließenden Verwendung gesendet werden.

Token-Validierung

1. Für nachfolgende API-Anfragen sendet der Client das JWT im Authorization-Header (Bearer <token>).
2. Der Server überprüft die Signatur des JWT mit einem geheimen oder öffentlichen Schlüssel und prüft dessen Ansprüche (z.B. Ablauf, Aussteller).
3. Wenn das Token gültig ist, gewährt der Server dem Client Zugriff auf die angeforderten Ressourcen.

Sitzungsbasierte Authentifizierung erfordert, dass der Server einen Sitzungsstore abfragt, was langsam sein kann, insbesondere wenn es sich auf externe oder zentralisierte Datenbanken verlässt. Im Gegensatz dazu ist die JWT-Authentifizierung zustandslos, mit allen notwendigen Informationen, die im Client-Token gespeichert sind, und nutzt Signaturen, um Sicherheit zu gewährleisten. Dies eliminiert die Notwendigkeit für Sitzungsmanagement, was es schneller und skalierbarer macht, insbesondere in verteilten Systemen.

Wie widerruft man ein JWT?#

Auf der Clientseite bedeutet das Abmelden in der Regel das Löschen der lokalen Sitzung und das Entfernen von Token (ID, Zugriff, Refresh-Token) aus dem Speicher. Für die JWT-Authentifizierung meldet dies jedoch nur lokal ab und lässt die zentrale Sitzung auf dem Berechtigungsserver intakt. Dadurch können Benutzer möglicherweise weiterhin auf andere Apps mit derselben Sitzung zugreifen, bis das Token abläuft oder manuell beendet wird.

Das Widerrufen eines JWT (JSON Web Token) ist herausfordernder als bei sitzungsbasierter Authentifizierung, da JWTs zustandslos sind und nicht ungültig gemacht werden können, sobald sie ausgestellt sind, es sei denn, es werden spezifische Strategien implementiert. Häufige Methoden umfassen:

• Kurze Ablaufzeiten: Setze einen kurzen exp-Anspruch (z.B. 15 Minuten) für das JWT. Nach dem Ablauf muss sich der Benutzer erneut authentifizieren. Dies minimiert das Risiko, wenn ein Token kompromittiert wird, da der Angreifer es nur für eine begrenzte Zeit verwenden kann. Um ein nahtloses Benutzererlebnis zu gewährleisten, kann ein Aktualisierungstoken verwendet werden, um die Unannehmlichkeiten der erneuten Authentifizierung zu minimieren.
• Token-Blacklist: Für kritische Fälle (z.B. Benutzerabmeldung, Passwortänderungen) eine Blacklist von widerrufenen Token führen. Der Server überprüft eingehende Token gegen diese Blockliste und lehnt Übereinstimmungen ab. Obwohl effektiv, erfordert dieser Ansatz das Verfolgen von widerrufenen Token, was der zustandslosen Natur von JWTs widerspricht und ineffizient werden kann, wenn die Liste zu groß wird.
• Widerrufs-Endpunkt: Einführung eines Widerrufs-Endpunkts auf dem Autorisierungsserver, an dem Token (z.B. Refresh-Token) ungültig gemacht werden können. Sobald ein Refresh-Token widerrufen wird, werden alle daraus ausgestellten Zugriffstoken nicht mehr erneuert. Diese Methode funktioniert gut in OAuth2-Flüssen.

Vorteile der JWT-Authentifizierung#

• Schnell und informativer: Die eigenständige Natur von JWTs macht die Verifizierung auf der Clientseite schneller und effizienter, ohne die Notwendigkeit einer Serverinteraktion. Sie können auch benutzerdefinierte Claim (z.B. Benutzerrollen oder andere relevante Daten) innerhalb des Tokens enthalten, was es den Servern ermöglicht, Rollen zu bestimmen, ohne eine Datenbank abfragen zu müssen.
• Erhöhte Sicherheit: JWTs verwenden Signatur- und Verschlüsselungstechniken, um Angriffe zu erschweren.
• Domainübergreifender Support: JWTs sind perfekt für Single Sign-On (SSO) und domainübergreifende Authentifizierung geeignet. Sie ermöglichen es Benutzern, sich über mehrere Domains oder Dienste mit demselben Token zu authentifizieren.
• Mobilfreundlich: JWTs funktionieren gut für mobile Anwendungen, die zustandslose Authentifizierung benötigen. Tokens können auf der Clientseite gespeichert und mit jeder Anfrage gesendet werden, was Effizienz und Benutzerfreundlichkeit verbessert.

Nachteile der JWT-Authentifizierung#

• JWT wird nicht in Echtzeit aktualisiert

  Sobald ein JWT signiert ist, kann es nicht widerrufen oder aktualisiert werden, und es wird als gültig angesehen, solange die Signatur gültig ist und nicht abgelaufen ist.

  Wenn sich die Zugriffsrechte eines Benutzers ändern (in der Regel verschlechternd), hat der Benutzer weiterhin entfernten Zugriff auf die Ressourcen, bis das JWT abläuft. Ähnlich, wenn ein JWT rollenbasierte Autorisierungsinformationen enthält, wird der neue Autorisierungsumfang nicht in Kraft treten, bis das alte JWT abläuft. Mit anderen Worten, JWTs sind nicht für Echtzeit-Widerrufe geeignet, und Benutzer können eine angemessene Ablaufzeit festlegen, um dieses Problem zu mildern.

• Mehrgeräte- und Widerrufsdilemma

  Es ist nicht möglich, alle ausgegebenen JWTs zu validieren, bevor sie ablaufen, um Benutzern eine Widerrufung auf allen Geräten zu ermöglichen. Während es theoretisch möglich ist, den Signaturschlüssel zu widerrufen, um das JWT ungültig zu machen, würde dies auch alle JWTs ungültig machen, die diesen Schlüssel verwenden, und der Prozess der Behandlung von Cache-Schlüsseln würde diesen Ansatz für einfache Benutzerwiderrufsoperationen unpraktisch machen.

Einige Identitätsanbieter können vorgefertigte Lösungen für diese JWT-Probleme haben. Für weitere Informationen, siehe "Best Practices zur Verbesserung der JWT-Authentifizierungserfahrung.”

Was ist der Unterschied zwischen JWT und Sitzung?#

Sitzungen und JWTs sind zwei beliebte Ansätze zur Speicherung von Authentifizierungs- und Autorisierungskontext in einer zustandslosen HTTP-Welt. Während beide Ansätze ihre Vor- und Nachteile haben, bieten sie unterschiedliche Vorteile und Nachteile.

Sitzungen bieten stärkere Garantien für die Autorisierung einzelner Anfragen und sind einfacher sicher zu implementieren. Ihre Abhängigkeit von serverseitiger Datenbankvalidierung führt jedoch zu Latenzüberhead, der sich negativ auf die Benutzererfahrung von hochreaktiven Anwendungen auswirken kann.

JWTs hingegen sind vorteilhaft für schnellere Autorisierung und Interoperabilität mit externen Apps, erfordern jedoch mehr Entwickleraufwand zur Lösung von Sicherheitskomplexitäten. Zum Beispiel können wir Webhooks verwenden, um Clients zu benachrichtigen, wenn der Zugriff des Benutzers widerrufen wird, damit Clients das zwischengespeicherte JWT löschen und den Benutzer zur erneuten Authentifizierung zwingen können.

Da Token-basierte Authentifizierung besser zur Skalierung geeignet ist und ihre Nachteile dennoch handhabbar sind, wird sie von immer mehr modernen Anwendungen übernommen.

Sitzung vs. JWT: Die richtige Methode wählen#

Deine Authentifizierungsmethode sollte zur Architektur und den spezifischen Anforderungen deiner App passen. Hier ist ein kurzer Leitfaden, um bei der Entscheidung zu helfen:

Wann sollte man sitzungsbasierte Authentifizierung verwenden#

Sitzungsbasierte Authentifizierung funktioniert am besten, wenn du Echtzeit-Sitzungssteuerung benötigst, zentrale Verwaltung benötigst oder Skalierbarkeit kein großes Anliegen ist. Hier glänzt sie:

• Webanwendungen mit persistenten Sitzungen

  Für Plattformen wie Online-Shop-Websites sind Sitzungen unerlässlich, um Benutzer, Einkaufswagen und Vorlieben während ihres Besuchs zu verfolgen.

• Anwendungen, die Echtzeit-Sitzungssteuerung erfordern

  Anwendungen wie Banken- oder Finanzdienstleistungen profitieren von servergesteuerten Sitzungsdaten, die eine robuste Zugangskontrolle und Sicherheit gewährleisten.

• Einzelserver- oder Kleinmaßstabsysteme

  Interne Werkzeuge oder Kleinmaßstabs-Apps ohne schwere Skalierungsanforderungen profitieren von einfacher Sitzungsverwaltung für Benutzerfreundlichkeit und Zuverlässigkeit.

Wann sollte man JWT-Authentifizierung verwenden#

JWT-Authentifizierung ist besser geeignet für Anwendungen, die Skalierbarkeit, Effizienz und verteilte Systeme priorisieren. Sie ist besonders nützlich für zustandslose Interaktionen zwischen Clients und Servern. Betrachte tokenbasierte Authentifizierung für Folgendes:

• Single Sign-On (SSO)

  JWTs sind perfekt für Single Sign-On und ermöglichen es Benutzern, sich einmal zu authentifizieren und nahtlos auf mehrere Dienste oder Anwendungen mit demselben Token zuzugreifen. Teile eine detaillierte Erklärung über sichere cloudbasierte Anwendungen unter Verwendung von OAuth 2.0 und OIDC, mit JWT-Format für sowohl Zugriffstoken und ID-Tokens.

• Mobile Anwendungen

  Mobile Apps bevorzugen oft JWTs für die Authentifizierung, da Tokens sicher auf dem Gerät gespeichert und mit jeder API-Anfrage gesendet werden können. Erkunde die schnelle Integration der JWT-Authentifizierung für Android / iOS.

• Microservices-Architekturen

  In Microservices-Umgebungen ermöglichen es JWTs jedem Dienst, das Token unabhängig zu validieren, ohne sich auf einen zentralen Sitzungsstore zu verlassen, um Skalierbarkeit und Effizienz sicherzustellen.

• Domainübergreifende Authentifizierung

  JWTs sind hervorragend in Szenarien, die mehrere Domains oder Subdomains umfassen (z.B. api.example.com, dashboard.example.com und docs.example.com). Im Gegensatz zu Cookies ermöglichen JWTs Authentifizierung über Domains hinweg ohne zusätzliche Abhängigkeiten.

• APIs und Webdienste

  RESTful APIs und Webdienste nutzen häufig JWTs für die Authentifizierung, da sie leichtgewichtig, portabel sind und die Notwendigkeit für serverseitiges Sitzungsmanagement eliminieren. Erfahre mehr über Machine-To-Machine-Authentifizierung für Szenarien, in denen deine App direkt mit Ressourcen kommunizieren muss.

Best Practices zur Verbesserung der JWT-Authentifizierungserfahrung#

JWT-Authentifizierung ist ein großartiges Werkzeug, kann aber Herausforderungen mit sich bringen, die die Benutzererfahrung beeinträchtigen. Logto bietet eine einfache und zuverlässige Lösung, um diese Hürden zu überwinden und ist eine Top-Wahl für sichere und effiziente Authentifizierung.

Umgang mit Benutzerabmeldeproblemen mit JWT#

Ein häufiges Problem bei der JWT-Authentifizierung ist die Gewährleistung einer ordnungsgemäßen Benutzerabmeldungserfahrung. Logto vereinfacht diesen Prozess mit seinem Out-of-the-Box-SDK.

• Durch das Löschen von Tokens und lokalen Sitzungen auf der Client-Seite und durch Weiterleiten der Benutzer zum end session endpoint von Logto kannst du Sitzungen sowohl in der Client-Anwendung als auch auf dem Server leicht beenden.
• Zusätzlich unterstützt Logto back-channel logout, das es dem AuthServer ermöglicht, alle Client-Anwendungen, die dieselbe Sitzung teilen, zu benachrichtigen, wenn ein Benutzer sich abmeldet.

Dies gewährleistet ein konsistentes und sicheres Sitzungsmanagement in deinem Umfeld. Erfahre mehr über Abmeldemechanismen und wie man die Abmeldung implementiert.

Umgang mit Benutzerberechtigungsänderungen#

Das Management von Echtzeitänderungen bei Benutzerberechtigungen mit JWT kann auch schwierig sein. Da JWTs von Natur aus zustandslos sind, können aktualisierte Berechtigungen oder Rollen nicht wirksam werden, bis das Token abläuft. Logto bietet Strategien, um dies effektiv zu handhaben:

• Für das Verringern von Berechtigungen für diesen Benutzer: Verwende kurze Zugriffstokenablaufzeiten oder überprüfe Berechtigungen dynamisch über einen API-Aufruf.
• Für das Hinzufügen neuer Berechtigungen für diesen Benutzer: Aktualisiere den AuthServer, um den neuen Berechtigungsumfang einzuschließen und stimme die Benutzer neu ab, um diese Änderungen anzuwenden.

Diese Lösungen helfen, Berechtigungen auf dem neuesten Stand zu halten und ein sichereres, reaktiveres System zu gewährleisten. Erfahre mehr über das Management von Echtzeitänderungen bei Benutzerberechtigungen.

Logto, das eine skalierbare Infrastruktur für Identitätszugangsmanagement bietet, stellt eine vollständige Identitätslösung mit sowohl Cloud-Dienst als auch Open-Source-Version bereit.