JWT vs. Sitzungsbasierte Authentifizierung

Im Allgemeinen ist der erste Schritt bei der Nutzung einer Anwendung die Authentifizierung, bei der der Endbenutzer seine Identitätsnachweise angibt, 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 erinnert sich nicht an Informationen früherer Anfragen. Die Benutzer bei jeder Aktion erneut zu authentifizieren, ist umständlich und schadet der Benutzererfahrung.

Lassen Sie uns in die Sitzungsbasierte Authentifizierung und JWT (JSON Web Tokens) Authentifizierung eintauchen, zwei beliebte Methoden zum Aufrechterhalten des Authentifizierungsstatus. Jede hat ihre einzigartigen Vorteile und Kompromisse, und die Wahl zwischen ihnen hängt von den spezifischen Bedürfnissen Ihrer Anwendung ab. Wenn Sie zwischen den beiden entscheiden müssen, ist dieser Leitfaden da, um zu helfen.

Was ist sitzungsbasierte Authentifizierung?#

Die sitzungsbasierte Authentifizierung verlässt sich auf den Server, um einen Datensatz über den Authentifizierungsstatus des Benutzers zu führen. Indem er Sitzungen erstellt und verwaltet, ermöglicht der Server den Benutzern, angemeldet zu bleiben und mit einer Anwendung zu interagieren, ohne bei jeder Anfrage erneut Anmeldeinformationen eingeben zu müssen.

Wie funktioniert die 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 einen zufälligen String, Benutzerbezeichner, Sitzungsstartzeit, Ablaufzeit der Sitzung usw. 
3. Die SessionID wird in der Datenbank gespeichert und als Cookie an den Client des Nutzers zurückgegeben.

Sitzungsvalidierung

1. Der Prozess kann manuell vom Benutzer ausgelöst werden (z.B. durch Klicken auf einen Tab, Aktualisieren einer Seite) oder automatisch vom Client (z.B. während der ersten Seitenladung 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, bearbeitet 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 ein schneller Entzug des Zugriffs erforderlich ist.

• Benutzer loggen sich manuell aus: Der Server löscht den Sitzungsdatensatz, womit der Benutzer effektiv ausgeloggt wird.
• Admins zwingen Benutzer zum Ausloggen: Admins oder Systeme können eine bestimmte Sitzung beenden, indem sie sie aus der Datenbank löschen. Zum Beispiel bei einem Sicherheitsvorfall.
• Sitzungsablauf: Sitzungen können automatisch nach einer festgelegten Inaktivitätsdauer oder einer festen Zeitspanne ablaufen.

Vorteile der sitzungsbasierten Authentifizierung#

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

Nachteile der sitzungsbasierten Authentifizierung#

• Latenz in verteilten Systemen: Das Aufrechterhalten von Sitzungsdaten über mehrere Server hinweg erfordert immer die Synchronisierung eines Sitzungsspeichers. Dies führt zu zusätzlicher Latenz, da der Server bei jeder Anfrage den Sitzungsspeicher überprüfen muss.
• Hoher Ressourcenverbrauch: Jede Sitzung beansprucht Serverressourcen, was die Leistung beeinträchtigt, wenn die Nutzerbasis wächst.
• Sicherheitsrisiko: Das Hijacking von Sitzungen (über gestohlene Sitzungscookies) kann unbefugten Zugriff auf Benutzerkonten ermöglichen.
• Begrenzte Nutzung für APIs: Sitzungsbasierte Authentifizierung ist nicht ideal für mobile Apps. Sie speichert Sitzungsdaten auf dem Server, was bei vielen Benutzern die Last und Komplexität erhöhen kann. Außerdem verwendet sie Cookies, die auf mobilen Geräten schwieriger zu handhaben sind.

Was ist JWT-Authentifizierung?#

JSON Web Tokens (JWTs) gehen einen anderen Weg, 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 die JWT-Authentifizierung?#

Ein JWT besteht aus drei Teilen: einem header, payload und signature.

• Der header enthält den Signaturalgorithmus (z.B. HS256) und den Token-Typ (JWT).
• Der payload enthält wichtige Claims, wie z.B. die Benutzeridentität, Benutzerrolle und Ablaufzeit.
• Die signature verwendet einen Schlüssel, um den Header und die Nutzdaten zu signieren, damit überprüft werden kann, ob die Signatur manipuliert wurde.

JWT-Ausstellung

1. Der Client sendet Benutzerdaten 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, Nutzdaten und Signatur enthält.
3. Der AuthServer sendet das ausgestellte 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 Benutzerdaten auf dem Server innerhalb einer Sitzung gespeichert, während JWTs auf Tokens verlassen, die zur Speicherung und anschließenden Nutzung an den Client 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 JWTs mit einem geheimen oder öffentlichen Schlüssel und prüft dessen Claims (z. B. Ablauf, Aussteller).
3. Ist das Token gültig, gewährt der Server dem Client Zugriff auf die angeforderten Ressourcen.

Die sitzungsbasierte Authentifizierung erfordert, dass der Server einen Sitzungsstore abfragt, was langsam sein kann, insbesondere wenn es sich um externe oder zentrale Datenbanken handelt. Im Gegensatz dazu ist die JWT-Authentifizierung zustandslos, wobei alle notwendigen Informationen im Client-Token gespeichert und die Signatur zur Sicherstellung der Sicherheit verwendet wird. Dies eliminiert die Notwendigkeit eines Sitzungsmanagements, was sie schneller und skalierbarer macht, insbesondere in verteilten Systemen.

Wie wird ein JWT widerrufen?#

Auf der Client-Seite bedeutet das Abmelden in der Regel, dass die lokale Sitzung gelöscht und Tokens (ID, Zugriff, Aktualisierungstoken) aus dem Speicher entfernt werden. Aber bei der JWT-Authentifizierung meldet dies nur den Benutzer lokal ab und lässt die zentrale Sitzung auf dem Autorisierungsserver intakt. Infolgedessen können Benutzer möglicherweise immer noch auf andere Apps im selben Sitzung zugreifen, bis das Token abläuft oder manuell beendet wird.

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

• Kurze Ablaufzeiten: Setzen Sie einen kurzen exp-Anspruch (z.B. 15 Minuten) für das JWT fest. Nach 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 nutzen kann. Um eine nahtlose Benutzererfahrung zu gewährleisten, kann ein Refresh Token verwendet werden, um die Unannehmlichkeiten einer erneuten Authentifizierung zu minimieren.
• Token-Blacklist: Für kritische Fälle (z.B. Abmeldung des Benutzers, Passwortänderungen), führen Sie eine Blacklist widerrufener Tokens. Der Server prüft eingehende Tokens gegen diese Blockliste und lehnt Übereinstimmungen ab. Obwohl effektiv, erfordert dieser Ansatz die Verfolgung widerrufener Tokens, was gegen die zustandslose Natur von JWTs verstößt und ineffizient werden kann, wenn die Liste zu groß wird.
• Widerrufs-Endpunkt: Führen Sie einen Widerrufs-Endpunkt auf dem Autoriserungs-Server ein, an dem Tokens (z.B. Refresh-Tokens) ungültig gemacht werden können. Sobald ein Refresh-Tokens widerrufen wird, werden alle aus ihm ausgestellten Zugriffstokens nicht mehr erneuert. Diese Methode funktioniert gut in OAuth2 Flows.

Vorteile der JWT-Authentifizierung#

• Schnell und informativer: Die eigenständige Natur von JWTs ermöglicht eine schnellere und effizientere Überprüfung auf der Client-Seite, ohne dass eine Interaktion mit dem Server erforderlich ist. Sie können auch benutzerdefinierte Claims (z. B. Benutzerrollen oder andere relevante Daten) im Token enthalten, sodass Server Rollen bestimmen können, ohne eine Datenbank abzufragen.
• Erhöhte Sicherheit: JWTs verwenden Signatur- und Verschlüsselungstechniken, wodurch Angriffe erschwert werden.
• Unterstützung für mehrere Domänen: JWTs sind ideal für Single Sign-On (SSO) und Identitätsübergreifende Authentifizierung. Sie ermöglichen es Benutzern, sich über mehrere Domains oder Dienste hinweg mit demselben Token zu authentifizieren.
• Mobilfreundlich: JWTs eignen sich hervorragend für mobile Anwendungen, die eine zustandslose Authentifizierung benötigen. Tokens können auf der Client-Seite gespeichert und mit jeder Anfrage gesendet werden, was die Effizienz und Benutzerfreundlichkeit erhöht.

Nachteile der JWT-Authentifizierung#

• JWT wird nicht in Echtzeit aktualisiert

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

  Wenn sich die Zugriffsberechtigungen eines Benutzers ändern (meistens reduziert), bleibt der Zugriff des Benutzers auf die Ressourcen erhalten, bis das JWT abläuft. Ebenso, wenn ein JWT rolesbezogene Autorisierungsinformationen enthält, treten neue Autorisierungsbereiche erst in Kraft, wenn das alte JWT abläuft. Mit anderen Worten, JWTs sind nicht geeignet für Echtzeit-Widerruf, und Benutzer können eine geeignete Ablaufzeit festlegen, um dieses Problem zu mindern.

• Mehrere Geräte und Widerrufs-Dilemma

  Es ist nicht möglich, alle ausgegebenen JWTs vor ihrem Ablauf zu validieren, um den Benutzerwiderruf auf allen Geräten zu implementieren. Theoretisch ist es zwar möglich, den Signaturschlüssel zu widerrufen, um das JWT ungültig zu machen, aber dies würde auch alle JWTs mit diesem Schlüssel ungültig machen, und der Prozess der Handhabung von Schlüssel-Puffs würde diesen Ansatz für einfache Benutzerwiderrufsoperationen unpraktikabel machen.

Einige Identitätsanbieter haben möglicherweise bereits Lösungen für diese JWT-Probleme entwickelt. Weitere Informationen finden Sie unter „Best Practices zur Verbesserung der JWT-Authentifizierungserfahrung.”

Was ist der Unterschied zwischen JWT und Sitzung?#

Sitzungen und JWTs sind zwei beliebte Ansätze zur Persistierung des Authentifizierungs- und Autorisierungskontexts 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 der Validierung durch serverseitige Datenbanken führt jedoch zu zusätzlichen Latenzen, was sich negativ auf die Benutzererfahrung für hochgradig reaktionsschnelle Anwendungen auswirken kann.

JWTs hingegen sind vorteilhaft für schnellere Autorisierung und Interoperabilität mit externen Apps, erfordern jedoch mehr Entwickleraufwand, um Sicherheitskomplexitäten zu adressieren. Beispielsweise können Webhooks verwendet werden, um Clients zu benachrichtigen, wenn der Zugriff des Benutzers widerrufen wird, sodass Clients das zwischengespeicherte JWT löschen und den Benutzer zur erneuten Authentifizierung zwingen können.

Da tokenbasierte Authentifizierung besser für das Hochskalieren geeignet ist und ihre Nachteile noch beherrschbar sind, wird sie von immer mehr modernen Anwendungen übernommen.

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

Ihre Authentifizierungsmethode sollte zur Architektur und den spezifischen Anforderungen Ihrer App passen. Hier ist eine kurze Anleitung, die Ihnen bei der Entscheidung helfen soll:

Wann sollte die sitzungsbasierte Authentifizierung verwendet werden#

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

• Webanwendungen mit persistenten Sitzungen

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

• Anwendungen, die Echtzeit-Sitzungskontrolle erfordern

  Anwendungen wie Banken oder Finanzdienstleistungen profitieren von servergesteuerten Sitzungsdaten, die ein robustes Zugriffsmanagement und Sicherheit gewährleisten.

• Einzelserver oder kleinmaßstabige Systeme

  Interne Werkzeuge oder kleinmaßstabige Apps ohne große Skalierungsbedürfnisse profitieren von einfachem Sitzungsmanagement für Benutzerfreundlichkeit und Zuverlässigkeit.

Wann sollte die JWT-Authentifizierung verwendet werden#

JWT-Authentifizierung ist besser geeignet für Anwendungen, die Skalierbarkeit, Effizienz und verteilte Systeme priorisieren. Sie eignet sich besonders für zustandslose Interaktionen zwischen Clients und Servern. Überlegen Sie, ob die tokenbasierte Authentifizierung in den folgenden Szenarien sinnvoll ist:

• Single Sign-On (SSO)

  JWTs sind ideal 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. Geben Sie eine detaillierte Erklärung darüber ab, wie sichere Cloud-basierte Anwendungen mit OAuth 2.0 und OIDC mit JWT-Format sowohl für Zugriffstokens als auch für ID-Tokens unterstützen lassen.

• 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. Erkunden Sie die schnelle Integration von JWT-Authentifizierung für Android / iOS.

• Microservices-Architekturen

  In Microservices-Umgebungen ermöglichen JWTs jeder Dienst, das Token unabhängig zu validieren, ohne sich auf einen zentralen Sitzungspeicher zu verlassen, um Skalierbarkeit und Effizienz zu gewährleisten.

• Domänenübergreifende Authentifizierung

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

• APIs und Webdienste

  RESTful APIs und Webdienste verwenden häufig JWTs für die Authentifizierung, da sie leichtgewichtig, portabel sind und die Notwendigkeit eines serverseitigen Sitzungsmanagements entfällt. Erfahren Sie mehr über Machine-to-Machine-Authentifizierung für Szenarien, in denen Ihre App direkt mit Ressourcen kommunizieren muss.

Best Practices zur Verbesserung der JWT-Authentifizierungserfahrung#

Die JWT-Authentifizierung ist ein großartiges Werkzeug, kann aber Herausforderungen mit sich bringen, die die Benutzererfahrung beeinflussen. Logto bietet eine einfache und zuverlässige Lösung zur Überwindung dieser Hürden und macht es zu einer Top-Wahl für sichere und effiziente Authentifizierung.

Umgang mit Benutzerabmeldungen bei JWT#

Ein häufiges Problem bei der JWT-Authentifizierung ist die Sicherstellung eines ordnungsgemäßen Benutzerabmeldeerlebnisses. Logto vereinfacht diesen Prozess mit seinem sofort einsatzbereiten SDK.

• Durch das Löschen von Tokens und lokalen Sessions auf der Client-Seite und die Umleitung der Benutzer zum Logto Ende der Sitzung-Endpunkt, können Sie leicht Sessions sowohl auf der Client-Anwendung als auch auf dem Server beenden.
• Darüber hinaus unterstützt Logto Rückkanal-Abmelden, sodass der AuthServer alle Client-Anwendungen benachrichtigen kann, die die gleiche Sitzung teilen, wenn sich ein Benutzer abmeldet.

Dies gewährleistet konsistentes und sicheres Sitzungsmanagement in Ihrem gesamten Ökosystem. Erfahren Sie mehr über den Umgang mit der Abmeldung.

Umgang mit Änderungen der Benutzerberechtigungen#

Die Verwaltung von Echtzeitänderungen der Benutzerberechtigungen mit JWT kann ebenfalls schwierig sein. Da JWTs von Natur aus zustandslos sind, können aktualisierte Berechtigungen oder Rollen möglicherweise nicht in Kraft treten, bis das Token abläuft. Logto bietet Strategien, um damit effektiv umzugehen:

• Zum Reduzieren der Berechtigungen für diesen Benutzer: Verwenden Sie kurze Ablaufzeiten für Zugriffstokens oder überprüfen Sie Berechtigungen dynamisch über einen API-Aufruf.
• Zum Hinzufügen neuer Berechtigungen für diesen Benutzer: Aktualisieren Sie den AuthServer, um den neuen Berechtigungsbereich einzuschließen und fordern Sie Benutzer erneut auf, diese Änderungen zu akzeptieren.

Diese Lösungen helfen, Berechtigungen auf dem Laufenden zu halten und sorgen für ein sichereres, reaktionsschnelleres System. Erfahren Sie mehr über den Umgang mit Berechtigungsänderungen.

Logto, das eine skalierbare Infrastruktur für Identitäts- und Zugriffsmanagement bietet, bietet eine vollständige Identitätslösung sowohl als Cloud-Dienst als auch in einer Open-Source-Version.