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.
user_idfür einen angemeldeten Benutzer enthält.