Ich habe einige Beiträge über "JWT vs Cookie" gelesen, aber sie haben mich nur verwirrter gemacht ...

1. Ich möchte eine Klarstellung , wenn Leute über "tokenbasierte Authentifizierung gegen Cookies" sprechen, beziehen sich Cookies hier lediglich auf Sitzungscookies ? Meines Wissens nach ist Cookie wie ein Medium . Es kann verwendet werden, um eine tokenbasierte Authentifizierung (speichern Sie etwas, das angemeldete Benutzer auf der Clientseite identifizieren kann ) oder eine sitzungsbasierte Authentifizierung (Speichern einer Konstante auf der Clientseite) zu implementieren das entspricht den Sitzungsinformationen auf der Serverseite )

2. Warum brauchen wir JSON-Web-Token ? Ich habe das Standard-Cookie verwendet, um die tokenbasierte Authentifizierung zu implementieren ( keine Sitzungs-ID, kein Server- oder Dateispeicher ): Set-Cookie: user=innocent; preferred-color=azureund der einzige Unterschied, den ich festgestellt habe, ist, dass JWT sowohl Nutzdaten als auch Signaturen enthält ... während Sie wählen können zwischen signiertem oder Klartext- Cookie für http-Header. Meiner Meinung nach ist signiertes cookie ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') platzsparender. Der einzige Nachteil ist, dass der Client das Token nicht lesen kann, nur der Server ... aber ich denke, es ist in Ordnung, da genau wie die Behauptung in JWT optional ist, es für das Token nicht erforderlich ist sinnvoll sein

Der größte Unterschied zwischen Inhaber-Token und Cookies besteht darin, dass der Browser automatisch Cookies sendet , bei denen Träger-Token explizit zur HTTP-Anforderung hinzugefügt werden müssen.

Diese Funktion macht Cookies zu einer guten Möglichkeit, Websites zu sichern, auf denen sich ein Benutzer anmeldet und mithilfe von Links zwischen den Seiten navigiert.

Der Browser, der automatisch Cookies sendet, hat auch einen großen Nachteil, nämlich CSRF- Angriffe. Bei einem CSRF-Angriff nutzt eine böswillige Website die Tatsache, dass Ihr Browser automatisch Authentifizierungscookies an Anforderungen an diese Domain anfügt und Ihren Browser dazu verleitet, eine Anforderung auszuführen.

Angenommen, auf der Website unter https://www.example.com können authentifizierte Benutzer ihre Kennwörter ändern, indem sie POSTdas neue Kennwort auf https://www.example.com/changepassword setzen, ohne dass der Benutzername oder das alte Kennwort veröffentlicht werden muss.

Wenn Sie beim Besuch einer schädlichen Website, die eine Seite in Ihrem Browser lädt, die einen POST an diese Adresse auslöst, immer noch auf dieser Website angemeldet sind, hängt Ihr Browser die Authentifizierungscookies genau an, sodass der Angreifer Ihr Kennwort ändern kann.

Cookies können auch zum Schutz von Webdiensten verwendet werden, aber heutzutage werden Inhaber-Token am häufigsten verwendet. Wenn Sie zum Schutz Ihres Webdienstes Cookies verwenden, muss dieser Dienst in der Domain leben, für die die Authentifizierungscookies gesetzt sind, da die Richtlinie mit demselben Ursprung keine Cookies an eine andere Domain sendet.

Cookies erschweren es auch nicht browserbasierten Anwendungen (wie Apps für Mobilgeräte oder Tablets), Ihre API zu nutzen.

Überblick

Was Sie verlangen, ist der Unterschied zwischen Cookies und Inhaber-Token zum Senden von JSON-Web-Tokens (JWTs) vom Client an den Server.

Sowohl Cookies als auch Inhaber-Token senden Daten.

Ein Unterschied besteht darin, dass Cookies zum Senden und Speichern beliebiger Daten dienen, während Inhaber-Token speziell zum Senden von Autorisierungsdaten dienen.

Diese Daten werden häufig als JWT codiert.

Plätzchen

Ein Cookie ist ein Name-Wert-Paar, das in einem Webbrowser gespeichert ist und ein Ablaufdatum und eine zugehörige Domain hat.

Wir speichern Cookies in einem Webbrowser entweder mit JavaScript oder mit einem HTTP-Antwortheader.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Der Webbrowser sendet bei jeder Anfrage automatisch Cookies an die Domain des Cookies.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Inhaber-Token

Ein Inhaber-Token ist ein Wert, der in den AuthorizationHeader einer HTTP-Anforderung aufgenommen wird. Es wird nicht automatisch irgendwo gespeichert, es hat kein Ablaufdatum und keine zugeordnete Domain. Es ist nur ein Wert. Wir speichern diesen Wert manuell in unseren Clients und fügen diesen Wert manuell dem HTTP-Autorisierungsheader hinzu.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT- und Token-basierte Authentifizierung

Wenn wir eine tokenbasierte Authentifizierung wie OpenID, OAuth oder OpenID Connect durchführen, erhalten wir von einer vertrauenswürdigen Stelle ein access_token (und manchmal auch ein id_token). Normalerweise möchten wir es speichern und zusammen mit HTTP-Anfragen für geschützte Ressourcen senden. Wie machen wir das?

Option 1 besteht darin, die Token in einem Cookie zu speichern. Dies übernimmt die Speicherung und sendet die Token im CookieHeader jeder Anforderung automatisch an den Server . Der Server analysiert dann das Cookie, überprüft die Token und antwortet entsprechend.

Eine andere Möglichkeit besteht darin, das Token im lokalen / Sitzungsspeicher zu speichern und dann den AuthorizationHeader jeder Anforderung manuell festzulegen. In diesem Fall liest der Server den Header und fährt wie bei einem Cookie fort.

Es lohnt sich, die verknüpften RFCs zu lesen, um mehr zu erfahren.

Zusätzlich zu dem, was MvdD über das automatische Senden von Cookies gesagt hat:

1. Ein Cookie kann ein Medium sein, aber seine wichtigste Funktion ist die Interaktion mit dem Browser. Cookies werden vom Server gesetzt und auf ganz bestimmte Weise in Anfragen gesendet. JWT hingegen ist ausschließlich ein Medium, es ist eine Behauptung einiger Tatsachen in einer bestimmten Struktur. Wenn Sie so geneigt wären, könnten Sie ein JWT als Authentifizierungscookie verwenden. Wenn Sie Artikel lesen, in denen sie verglichen werden, geht es in der Regel um die Verwendung eines JWT, der als Träger-Token per Front-End-Code gesendet wird, und eines Authentifizierungs-Cookies, das einer zwischengespeicherten Sitzung oder Benutzerdaten im Back-End entspricht.
2. JWT bietet viele Funktionen und setzt sie in einen Standard, damit sie zwischen Parteien verwendet werden können. Ein JWT kann an vielen verschiedenen Stellen als unterschriebene Behauptung einiger Tatsachen dienen. Ein Cookie, egal welche Daten Sie darin ablegen oder ob Sie es signieren, ist nur zwischen einem Browser und einem bestimmten Backend sinnvoll. JWT kann vom Browser zum Back-End, zwischen Back-Ends, die von verschiedenen Parteien gesteuert werden (OpenId Connect ist ein Beispiel), oder innerhalb von Back-End-Diensten einer Partei verwendet werden. In Bezug auf Ihr spezifisches Beispiel für Ihre signierten Cookies können Sie in diesem Anwendungsfall wahrscheinlich dieselben Funktionen ("keine Sitzungs-ID verwenden, keinen Serverspeicher oder Dateispeicher verwenden") wie JWT erzielen, aber Sie verlieren Bibliotheken und Peer-Review von der Standard, zusätzlich zu den CSRF-Fragen, über die in der anderen Antwort gesprochen wurde.

Zusammenfassend: In den Posts, die Sie lesen, wird JWT wahrscheinlich als Inhaber-Token mit dem Authentifizierungs-Cookie für die Browser-Server-Authentifizierung verglichen. JWT kann jedoch noch viel mehr. Es bietet Standardisierung und Funktionen für die Verwendung außerhalb des Anwendungsfalls, an den Sie wahrscheinlich denken.

Cookies können das Risiko von CSRF-Angriffen erhöhen, da sie automatisch zusammen mit Anforderungen gesendet werden . Sie können jedoch das Risiko von XSS-Angriffen verringern, wenn das HttpOnlyFlag gesetzt ist, da Skripte, die in die Seite eingefügt werden, nicht lesen können der Keks.

CSRF: Ein Benutzer klickt auf einen Link (oder zeigt Bilder an) auf der Website eines Angreifers, wodurch der Browser eine Anfrage an die Website des Opfers sendet. Wenn das Opfer Cookies verwendet, nimmt der Browser das Cookie automatisch in die Anforderung auf. Wenn die GET-Anforderung nicht schreibgeschützte Aktionen auslösen kann, ist die Website des Opfers für den Angriff anfällig.

XSS: Ein Angreifer bettet ein Skript in die Opfer-Site ein (die Opfer-Site ist nur anfällig, wenn Eingaben nicht korrekt bereinigt werden), und das Skript des Angreifers kann alles tun, was Javascript auf der Seite tun darf. Wenn Sie JWT-Token im lokalen Speicher speichern, kann das Skript des Angreifers diese Token lesen und diese Token auch an einen von ihnen kontrollierten Server senden. Wenn Sie Cookies mit dem HttpOnlyFlag verwenden, kann das Skript des Angreifers Ihr Cookie zunächst nicht lesen. Das Skript, das sie erfolgreich injiziert haben, kann jedoch weiterhin alles tun, was Javascript kann. Sie sind also immer noch IMO abgespritzt (dh sie können das Cookie möglicherweise nicht lesen, um es zur späteren Verwendung an ihren eigenen Server zu senden sie können XHR - Anfragen an den vicitim Ihre Nutzung der Webseite senden , die das Cookie enthalten wird sowieso).

Ref - Bedarf an JSON-Web-Token

Kekse

Bei Cookies erstellt der Google Mail-Server nach der Authentifizierung des Benutzers eine eindeutige Sitzungs-ID. Entsprechend dieser Sitzungs-ID werden alle Benutzerinformationen im Speicher gespeichert, die der Google Mail-Server benötigt, um den Benutzer zu erkennen und Vorgänge auszuführen.
Auch dann wird für alle nachfolgenden Anfragen und Antworten diese Sitzungs-ID übergeben. Wenn der Server nun eine Anfrage erhält, überprüft er die Sitzungs-ID. Wenn Sie diese Sitzungs-ID verwenden, wird überprüft, ob entsprechende Informationen vorhanden sind. Anschließend kann der Benutzer auf die Ressource zugreifen und die Antwort zusammen mit der Sitzungs-ID zurückgeben.

Nachteile von Cookies

• Cookies / Sitzungs-ID sind nicht eigenständig. Es ist ein Referenz-Token. Bei jeder Überprüfung muss der Google Mail-Server die entsprechenden Informationen abrufen.
• Nicht geeignet für Microservices-Architekturen mit mehreren APIs und Servern

JWT

• JWT ist in sich geschlossen. Es ist ein Wert-Token. Daher muss der Google Mail-Server bei jeder Überprüfung nicht die entsprechenden Informationen abrufen.
• Es ist digital signiert. Wenn jemand es ändert, weiß der Server davon
• Es ist am besten für die Microservices-Architektur geeignet
• Es hat andere Vorteile wie die Angabe der Ablaufzeit.