Ich habe ein paar Posts über "JWT vs Cookie" gelesen, aber sie haben mich nur noch verwirrter gemacht ...
Ich möchte etwas klären , wenn Leute über "tokenbasierte Authentifizierung im Vergleich zu Cookies" sprechen, beziehen sich Cookies hier lediglich auf Sitzung Cookies ? Nach meinem Verständnis ist Cookie wie ein Medium , es kann verwendet werden, um eine tokenbasierte Authentifizierung zu implementieren (speichert etwas, das angemeldeten Benutzer auf der Clientseite identifizieren kann). oder eine sitzungsbasierte Authentifizierung (speichern Sie eine Konstante auf der Clientseite, die den Sitzungsinformationen auf der Serverseite entspricht)
Warum benötigen wir das JSON-Web-Token ? Ich verwendete den Standard-Cookie zur Implementierung der tokenbasierten Authentifizierung ( keine Sitzungs-ID, keinen Serverspeicher oder Dateispeicher verwenden ): Set-Cookie: user=innocent; preferred-color=azure , und der einzige Unterschied, den ich beobachtete, ist, dass JWT beides enthält Nutzlast und Signatur ... wobei Sie zwischen signed oder plaintext Cookie für HTTP-Header wählen können. Meiner Meinung nach ist Cookie ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM' ) platzsparender, der einzige Nachteil ist, dass der Client das Token nicht lesen kann, nur der Server kann ... aber ich denke, es ist in Ordnung, genau wie claim in JWT ist optional, es ist nicht notwendig, dass das Token sinnvoll ist
Der größte Unterschied zwischen Bearer Tokens und Cookies besteht darin, dass der Browser automatisch Cookies sendet, wobei Bearer Token explizit zur HTTP-Anfrage hinzugefügt werden müssen.
>Diese Funktion macht Cookies zu einer guten Möglichkeit, Websites zu sichern, auf denen sich ein Benutzer anmeldet und zwischen den Seiten mit Links navigiert.
Der Browser, der automatisch Cookies sendet, hat auch einen großen Nachteil: CSRF Angriffe . Bei einem CSRF-Angriff nutzt eine bösartige Website die Tatsache aus, dass Ihr Browser automatisch Authentifizierungscookies an Anfragen an diese Domain anfügt und Ihren Browser dazu bringt, eine Anfrage auszuführen.
Angenommen, auf der Website Ссылка können authentifizierte Benutzer ihre Kennwörter durch POST ändern und das neue Kennwort in Ссылка , ohne dass der Benutzername oder das alte Passwort veröffentlicht werden muss.
Wenn Sie immer noch auf dieser Website angemeldet sind, wenn Sie eine bösartige Website besuchen, die eine Seite in Ihren Browser lädt, die einen POST an diese Adresse auslöst, hängt Ihr Browser die Authentifizierungscookies originalgetreu an, damit der Angreifer Ihr Passwort ändern kann.
Cookies können auch verwendet werden, um Web-Services zu schützen, aber heutzutage werden am häufigsten Bearer-Token verwendet. Wenn Sie Cookies zum Schutz Ihres Webdienstes verwenden, muss dieser Dienst in der Domäne enthalten sein, für die die Authentifizierungscookies festgelegt sind, z. B. Richtlinie gleichen Ursprungs sendet keine Cookies an eine andere Domain.
Cookies erschweren auch nicht browserbasierten Anwendungen (z. B. Apps für Smartphones oder Tablets) die Verwendung Ihrer API.
Sie fragen nach dem Unterschied zwischen Cookies und Trägertokens zum Senden von JSON-Webtoken (JWTs) vom Client an den Server.
Sowohl Cookies als auch Trägertokens senden Daten.
Ein Unterschied besteht darin, dass Cookies zum Senden und Speichern beliebiger Daten dienen, während Bearer-Tokens speziell zum Senden von Autorisierungsdaten dienen.
Diese Daten werden oft als JWT codiert.
Ein Cookie ist ein Name-Wert-Paar, das in einem Webbrowser gespeichert wird und ein Ablaufdatum und die zugehörige Domain hat.
Wir speichern Cookies in einem Webbrowser entweder mit JavaScript oder mit einem HTTP Response-Header.
%Vor%Der Webbrowser sendet automatisch Cookies mit jeder Anfrage an die Domain des Cookies.
%Vor% Ein Bearer-Token ist ein Wert, der in den Header Authorization einer beliebigen HTTP-Anforderung eingefügt wird. Es wird nicht automatisch gespeichert, es hat kein Ablaufdatum und keine zugehörige Domain. Es ist nur ein Wert. Wir speichern diesen Wert manuell in unseren Clients und fügen diesen Wert manuell zum HTTP-Autorisierungsheader hinzu.
Wenn wir eine tokenbasierte Authentifizierung wie OpenID, OAuth oder OpenID Connect durchführen, erhalten wir ein access_token (und manchmal id_token) von einer vertrauenswürdigen Autorität. 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. Dieser behandelt den Speicher und sendet die Token automatisch an den Server im Header Cookie jeder Anfrage. Der Server analysiert dann den Cookie, überprüft die Token und reagiert entsprechend.
Eine weitere Option besteht darin, das Token im lokalen / Sitzungsspeicher zu speichern und anschließend den Header Authorization jeder Anforderung manuell festzulegen. In diesem Fall liest der Server den Header und fährt wie bei einem Cookie fort.
Es lohnt sich, die verlinkten RFCs zu lesen, um mehr zu erfahren.
Zusätzlich zu dem, was MvdD über das automatische Senden von Cookies gesagt hat:
Zusammenfassend: Die Posts, die Sie lesen, vergleichen wahrscheinlich JWT als Bearer-Token mit einem Authentifizierungs-Cookie für Browser-zu-Server-Authentifizierungszwecke. Aber JWT kann viel mehr, es bringt Standardisierung und Funktionen für den Einsatz außerhalb des Anwendungsfalles, an den Sie wahrscheinlich denken.
Tags und Links json authentication cookies