Cookie vs. Session vs JWT

12

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!

user3629892
quelle

Antworten:

12

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, die key-valueursprünglich adressiert wurden, um Daten zu speichern, die sich auf die Kundenaktivität beziehen. Diese Aufbewahrung wird als Sitzungs- oder Anwendungsstatus bezeichnet . 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) gesetzt. 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 ordnen eher die terna data - client - server / path zu . (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 meinen Sie 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 sind Ansprüche ; Elemente, die vom Autorisierungsprozess überprüft werden sollen.

Es ist wichtig zu bedenken, 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 betrachtet die OWASP-Community den sessionStorage als den sichereren für Webbrowser. Dies hängt jedoch 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 statusbehaftete Anwendung.

3: Client als Anwendung, nicht als Benutzer.

Laiv
quelle
Ich würde beachten, dass einige, wie die Standardkonfiguration von Ruby on Rails, das gesamte "Sitzungs" -Objekt in einem Cookie speichern (heutzutage normalerweise verschlüsselt), das möglicherweise einfach so etwas wie user_idfür einen angemeldeten Benutzer enthält.
Fire Lancer
7

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 Set-Cookievom Server über den HTTP-Antwortheader ( ) festgelegt und von Clients gespeichert wird, die sie unterstützen. Cookies werden mit jeder nachfolgenden Anforderung (im CookieHeader) für Anforderungen zurückgesendet, die Schema, Host, Pfad und https entsprechen, während das Cookie noch 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:

Geben Sie hier die Bildbeschreibung ein

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.

Samuel
quelle
JWTs werden meiner Erfahrung nach normalerweise nicht in Cookies gespeichert. Sie könnten es sein, aber ich habe sie häufiger in ihren eigenen Headern (oder häufig im Autorisierungsheader) auf dem Weg zum Server gesehen und entweder im Speicher oder im lokalen oder Sitzungsspeicher auf dem Client gespeichert.
Paul
1
@ Paul bezüglich lokaler Speicherung. Das hängt vom Kunden ab. Nicht alle Clients und nicht alle Versionen der am häufigsten verwendeten Clients unterstützen den Webspeicher. Schauen Sie hier . Wenn dies der Fall ist, ist es vorzuziehen , Token saisonal herzustellen . Wenn unsere Kunden jedoch keinen lokalen Speicher unterstützen; Httponly Cookies + SSL + Client fingerPrints bieten uns eine ziemlich sichere Implementierung.
Laiv
@Laiv Ich bin nicht anderer Meinung als du; nur dass Samuel sagte, dass "das Token in einem Cookie gespeichert ist", und ich versuchte nur zu beobachten, dass dies nicht immer der Fall ist.
Paul
@ Paul Ich änderte mich zu lesen "... kann in einem Cookie gespeichert werden"
Samuel