it-swarm.com.de

Cookie vs. Session vs JWT

Ich lese über Authentifizierung/Autorisierung in Webanwendungen. Könnte jemand mein aktuelles Wissen bestätigen/korrigieren?

  • Cookies: In ihrer frühen Version eine Textdatei mit einer eindeutigen Client-ID und allen anderen Informationen, die über den Client benötigt werden (z. B. Rollen).

  • Sitzung: In einer Datei (auch Cookie genannt) wird nur die eindeutige Client-ID gesendet, alles andere wird auf dem Server gespeichert

  • JWT: Alles wird im Token gespeichert (das auch in einer Textdatei gespeichert werden kann, die auch als Cookie bezeichnet wird).

Vielen Dank für jedes Feedback!

12
user3629892

Cookies: In ihrer frühen Version eine Textdatei mit einer eindeutigen Client-ID und allen anderen Informationen, die über den Client benötigt werden (z. B. Rollen).

Cookies sind Tupel key-value ursprünglich adressiert an behalten Daten im Zusammenhang mit der Clientaktivität. Diese Aufbewahrung ist das, was wir als Sitzung oder Anwendungsstatus kennen. Grundsätzlich wurden sie für den Status von Webanwendungen erstellt. genauer gesagt, der Zustand auf der Clientseite. (1)

Cookies werden normalerweise vom Server über Antwortheader (Set-Cookie key=value). Sie können jedoch auch vom Client festgelegt werden. Zum Beispiel von DOM (document.cookie).

Eine wichtige Sache, die Sie über Cookies wissen sollten, ist, dass sie keine Benutzer identifizieren. Sie assoziieren eher die terna Daten - Client - Server/Pfad(3)

Wir verknüpfen Cookies normalerweise mit Dateien, da sie in den frühen Tagen der Webbrowser die Cookies irgendwie beibehalten mussten, da Dateien die bestmögliche Unterstützung darstellen. Heutige Browser speichern Cookies (unter anderem) in lokalen Speichern (eingebettete DBs).

Sitzung: In einer Datei (auch Cookie genannt) wird nur die eindeutige Client-ID gesendet, alles andere wird auf dem Server gespeichert.

Mit Sitzung meine ich wohl Serversitzungen. Wie ich bereits sagte, können Sitzungen auch auf der Clientseite implementiert werden. Der Unterschied zu clientseitigen Sitzungen besteht darin, dass die Daten irgendwo auf der Serverseite gespeichert werden. (2) In solchen Szenarien erhalten wir eine Sitzungs-ID. und wir bekommen es in Form von Cookie. Ohne die Sitzungs-ID wäre der Server nicht in der Lage, die eingehenden Anforderungen mit der vorherigen Aktivität des Clients zu korrelieren. (3) Zum Beispiel der authentifizierte Benutzer, der Warenkorb usw.

In jedem Fall identifiziert eine Sitzungs-ID nicht unbedingt einen Benutzer. Es ordnet einem Webclient einen bestimmten Anwendungsstatus zu. Sitzungen können Benutzerdaten enthalten oder nicht.

In verteilten Anwendungen sollte die Sitzung aus offensichtlichen Gründen serialisierbar sein. Wenn sie im Speicher gespeichert sind, sollte der speicherinterne Speicher (Komponente) serialisierbar sein. Eine übliche Lösung besteht darin, Sitzungen in Dateien zu speichern. Oder in NoSQL DB wie Redis.

In Bezug auf die Sicherheit. Serverseitige Sitzungen sind sicherer als clientseitige. Clients sind anfälliger für Bedrohungen, da Benutzer normalerweise nicht über die vielen Bedrohungen informiert sind, denen sie ausgesetzt sind. Zumindest nicht der normale Benutzer.

Andererseits ist der Angriff auf eine serverseitige Infrastruktur kein Trival.

JWT: Alles wird im Token gespeichert (das auch in einer Textdatei gespeichert werden kann, die auch als Cookie bezeichnet wird).

Nicht wirklich. JWT speichert Daten, die sich hauptsächlich auf die Autorisierung und den Aussteller des Tokens beziehen.

Obwohl sie die Benutzer-ID (Sub) enthalten, finden wir JWTs, die authentifizierte Benutzer nicht identifizieren. Zum Beispiel Token für Gästesitzungen. Der Hauptinhalt von JWTs ist Ansprüche; Elemente, die vom Autorisierungsprozess überprüft werden sollen.

Es ist wichtig zu beachten, dass JWTs keine globalen Speicher sind . Die Sitzung oder der Anwendungsstatus muss noch irgendwo gespeichert und unabhängig verwaltet werden.

In Bezug auf JWTs werden diese häufig als Cookies gespeichert, obwohl sie auch in lokalen Speichern gespeichert werden können. Darüber hinaus ist die OWASP-Community betrachtet den sessionStorage als den sichereren für Webbrowser. Jedoch es hängt von der Version des Browsers ab .


1: Das World Wide Web soll staatenlos sein. Wenn wir zustandslose serverseitige Anwendungen erstellen möchten, sollten Sitzungen irgendwo auf der Clientseite gespeichert werden.

2: Verwandeln der serverseitigen Anwendung in eine stateful Anwendung.

3: Client als Anwendung, nicht als Benutzer.

12
Laiv

Cookies: In ihrer frühen Version eine Textdatei mit einer eindeutigen Client-ID und allen anderen Informationen, die über den Client benötigt werden (z. B. Rollen).

Ihre Definition von Cookie beschreibt nicht wirklich, was sie tun. Ein Cookie ist ein Schlüssel-Wert-Paar, das über den HTTP-Antwortheader (Set-Cookie) vom Server und von Clients gespeichert, die sie unterstützen. Cookies werden mit jeder nachfolgenden Anforderung (im Header Cookie) für Anforderungen zurückgesendet, die mit Schema, Host, Pfad und https übereinstimmen, solange das Cookie nicht abgelaufen ist. Sie können alles, was Sie wollen, in einem Cookie speichern und den Status des zustandslosen HTTP-Protokolls unterstützen.

Ein Beispiel für den Austausch von Cookies sieht folgendermaßen aus:

(enter image description here

Sitzung: In einer Datei (auch Cookie genannt) wird nur die eindeutige Client-ID gesendet, alles andere wird auf dem Server gespeichert

Das ist ziemlich richtig. Eine Sitzung besteht aus Daten, die auf der Serverseite über die aktuelle Sitzung eines Benutzers gespeichert werden. Damit dies in einem zustandslosen Protokoll wie HTTP funktioniert, muss der Benutzer bei jeder Anforderung seine Sitzungs-ID senden, damit der Server die richtige Sitzung für den Benutzer abrufen kann. Die Sitzungs-ID wird normalerweise in einem Cookie gespeichert (siehe oben). Dies ist kein anderes Cookie als jedes andere Cookie. Die Daten sind lediglich die Server-ID für die Benutzersitzung.

JWT: Alles wird im Token gespeichert (das auch in einer Textdatei gespeichert werden kann, die auch als Cookie bezeichnet wird).

Das stimmt so ziemlich. Alles ist im Token gespeichert. Das Token kann in einem Cookie gespeichert werden (siehe oben). Dies ist eine Alternative zu Serversitzungen und funktioniert, da das Token vom Server signiert und überprüft wird, sodass es nicht geändert oder gefälscht werden kann und sicher auf der Clientseite gespeichert werden kann.

7
Samuel