Token-Authentifizierung vs. Cookies

Was ist der Unterschied zwischen Token-Authentifizierung und Authentifizierung mithilfe von Cookies?

Ich versuche, die Ember Auth Rails-Demo zu implementieren, verstehe jedoch nicht die Gründe für die Verwendung der Tokenauthentifizierung, wie in den häufig gestellten Fragen zur Emberauthentifizierung zur Frage "Warum Tokenauthentifizierung?" Beschrieben.

Eine typische Web-App ist aufgrund ihres Anforderungs- / Antwortcharakters größtenteils zustandslos . Das HTTP-Protokoll ist das beste Beispiel für ein zustandsloses Protokoll. Aber da die meisten Web - Anwendungen benötigen Zustand , um das zu halten Zustand , zwischen Server und Client werden Cookies verwendet , so dass der Server in jeder Antwort zurück an den Client senden. Dies bedeutet, dass die nächste vom Client gestellte Anforderung dieses Cookie enthält und somit vom Server erkannt wird. Auf diese Weise kann der Server eine Sitzung mit dem zustandslosen Client aufrechterhalten, wobei er fast alles über den Status der App weiß , jedoch auf dem Server gespeichert ist. In diesem Szenario hält der Client zu keinem ZeitpunktZustand , so funktioniert Ember.js nicht .

In Ember.js sieht es anders aus. Ember.js macht die Aufgabe des Programmierers erleichtert , weil es in der Tat das hält Zustand für Sie, in dem Kunden in jedem Moment über seine wissend Zustand ohne eine Anfrage an den Server zu fragen zu müssen Zustand Daten.

Das Halten des Status im Client kann jedoch manchmal auch zu Parallelitätsproblemen führen, die in zustandslosen Situationen einfach nicht vorhanden sind . Ember.js befasst sich jedoch auch mit diesen Problemen für Sie, insbesondere Ember-Daten werden unter diesem Gesichtspunkt erstellt. Zusammenfassend ist Ember.js ein Framework für Stateful Clients.

Ember.js funktioniert nicht wie eine typische zustandslose Webanwendung, bei der die Sitzung , der Status und die entsprechenden Cookies fast vollständig vom Server verarbeitet werden. Ember.js behält seinen Status vollständig in Javascript (im Speicher des Clients und nicht im DOM wie bei einigen anderen Frameworks) und benötigt den Server nicht, um die Sitzung zu verwalten. Dies führt dazu, dass Ember.js in vielen Situationen vielseitiger ist, z. B. wenn sich Ihre App im Offline-Modus befindet.

Aus Sicherheitsgründen muss natürlich jedes Mal, wenn eine Anforderung zur Authentifizierung gestellt wird , eine Art Token oder ein eindeutiger Schlüssel an den Server gesendet werden . Auf diese Weise kann der Server das Sendetoken (das ursprünglich vom Server ausgestellt wurde) und nachschlagen Überprüfen Sie, ob es gültig ist, bevor Sie eine Antwort an den Client zurücksenden.

Meiner Meinung nach liegt der Hauptgrund für die Verwendung eines Authentifizierungstokens anstelle von Cookies, wie in den häufig gestellten Fragen zu Ember Auth angegeben, hauptsächlich in der Natur des Ember.js-Frameworks und auch darin, dass es besser zum Stateful- Web-App-Paradigma passt . Daher ist der Cookie-Mechanismus nicht der beste Ansatz beim Erstellen einer Ember.js-App.

Ich hoffe, meine Antwort wird Ihrer Frage mehr Bedeutung verleihen.

HTTP ist zustandslos. Um Sie zu autorisieren, müssen Sie jede einzelne Anfrage, die Sie an den Server senden, "signieren".

Token-Authentifizierung

• Eine Anforderung an den Server wird mit einem "Token" signiert. In der Regel bedeutet dies, dass bestimmte http-Header festgelegt werden. Sie können jedoch in jedem Teil der http-Anforderung (POST-Text usw.) gesendet werden.

• Vorteile:

  • Sie können nur die Anfragen autorisieren, die Sie autorisieren möchten. (Cookies - sogar das Autorisierungscookie wird für jede einzelne Anfrage gesendet.)
  • Immun gegen XSRF (Kurzes Beispiel für XSRF - Ich sende Ihnen einen Link per E-Mail, der so aussieht <img src="http://bank.com?withdraw=1000&to=myself" />, und wenn Sie über eine Cookie-Authentifizierung bei bank.com angemeldet sind und bank.com keine XSRF-Mittel hat Schutz, ich werde Geld von Ihrem Konto einfach dadurch abheben, dass Ihr Browser eine autorisierte GET-Anfrage an diese URL auslöst.) Beachten Sie, dass es mit der Cookie-basierten Authentifizierung Maßnahmen gegen Fälschungen gibt, die Sie jedoch implementieren müssen.
  • Cookies sind an eine einzelne Domain gebunden. Ein auf der Domain foo.com erstelltes Cookie kann von der Domain bar.com nicht gelesen werden, während Sie Token an eine beliebige Domain senden können. Dies ist besonders nützlich für Anwendungen mit nur einer Seite, die mehrere Dienste benötigen, für die eine Autorisierung erforderlich ist. Daher kann ich eine Web-App in der Domain myapp.com einrichten, die autorisierte clientseitige Anforderungen an myservice1.com und myservice2.com senden kann.
• Nachteile:
  • Sie müssen den Token irgendwo aufbewahren. während Cookies "out of the box" gespeichert werden. Die Speicherorte, an die Sie denken, sind localStorage (con: das Token bleibt auch nach dem Schließen des Browserfensters erhalten), sessionStorage (pro: das Token wird nach dem Schließen des Browserfensters verworfen, con: Wenn Sie einen Link in einer neuen Registerkarte öffnen, wird diese Registerkarte gerendert anonym) und Cookies (Pro: Das Token wird verworfen, nachdem Sie das Browserfenster geschlossen haben. Wenn Sie ein Sitzungscookie verwenden, werden Sie beim Öffnen eines Links in einem neuen Tab authentifiziert und sind gegen XSRF immun, da Sie das ignorieren Cookie zur Authentifizierung, Sie verwenden es nur als Token-Speicher. Con: Cookies werden für jede einzelne Anfrage gesendet. Wenn dieses Cookie nicht nur als https markiert ist, sind Sie offen für Man-in-the-Middle-Angriffe.)
  • Es ist etwas einfacher, einen XSS-Angriff gegen die tokenbasierte Authentifizierung durchzuführen (dh wenn ich ein injiziertes Skript auf Ihrer Website ausführen kann, kann ich Ihr Token stehlen. Die Cookie-basierte Authentifizierung ist jedoch auch kein Wundermittel - während Cookies als gekennzeichnet sind Nur-http kann vom Client nicht gelesen werden. Der Client kann dennoch in Ihrem Namen Anfragen stellen, die automatisch das Autorisierungs-Cookie enthalten.)
  • Für das Herunterladen einer Datei, die nur für autorisierte Benutzer funktionieren soll, müssen Sie die Datei-API verwenden. Dieselbe Anforderung gilt sofort für die Cookie-basierte Authentifizierung.

Cookie-Authentifizierung

• Eine Anfrage an den Server wird immer durch ein Autorisierungscookie angemeldet.
• Vorteile:
  • Cookies können als "nur http" gekennzeichnet werden, sodass sie auf der Clientseite nicht gelesen werden können. Dies ist besser für den XSS-Angriffsschutz.
  • Kommt aus der Box - Sie müssen keinen Code auf der Client-Seite implementieren.
• Nachteile:
  • An eine einzelne Domain gebunden. (Wenn Sie also eine einseitige Anwendung haben, die Anfragen an mehrere Dienste stellt, können Sie verrückte Dinge wie einen Reverse-Proxy erledigen.)
  • Anfällig für XSRF. Sie müssen zusätzliche Maßnahmen ergreifen, um Ihre Site vor Fälschungen von standortübergreifenden Anfragen zu schützen.
  • Werden für jede einzelne Anfrage gesendet (auch für Anfragen, für die keine Authentifizierung erforderlich ist).

Insgesamt würde ich sagen, dass Token Ihnen eine bessere Flexibilität bieten (da Sie nicht an eine einzelne Domain gebunden sind). Der Nachteil ist, dass Sie einige Codierungen selbst vornehmen müssen.

• Tokens müssen irgendwo gespeichert werden (lokaler / Sitzungsspeicher oder Cookies)

• Token können wie Cookies verfallen, aber Sie haben mehr Kontrolle

• Lokaler / Sitzungsspeicher funktioniert nicht domänenübergreifend. Verwenden Sie ein Markierungscookie

• Preflight-Anfragen werden bei jeder CORS-Anfrage gesendet

• Wenn Sie etwas streamen müssen, verwenden Sie das Token, um eine signierte Anforderung zu erhalten

• Es ist einfacher, mit XSS umzugehen als mit XSRF

• Der Token wird bei jeder Anfrage gesendet. Achten Sie auf seine Größe

• Wenn Sie vertrauliche Informationen speichern, verschlüsseln Sie das Token

• JSON-Web-Token können in OAuth verwendet werden

• Token sind keine Silberkugeln. Denken Sie sorgfältig über Ihre Anwendungsfälle für die Autorisierung nach

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Für Googler :

• Mischen Sie NICHT Statefulness mit State Transfer-Mechanismen

STAATLICHKEIT

• Stateful = Autorisierungsinformationen auf der Serverseite speichern, dies ist der traditionelle Weg
• Statuslos = Autorisierungsinformationen auf der Clientseite zusammen mit einer Signatur speichern, um die Integrität sicherzustellen

MECHANISMEN

• Cookie = ein spezieller Header mit spezieller Behandlung (Zugriff, Speicherung, Ablauf, Sicherheit, automatische Übertragung) durch Browser
• Benutzerdefinierte Header = z. B. Authorizationsind nur Header ohne besondere Behandlung. Der Kunde muss alle Aspekte der Übertragung verwalten
• Andere . Andere Übertragungsmechanismen können verwendet werden, z. B. war die Abfragezeichenfolge eine Wahl, um die Authentifizierungs-ID für eine Weile zu übertragen, wurde jedoch wegen ihrer Unsicherheit aufgegeben

STAATLICHER VERGLEICH

• "Stateful Authorization" bedeutet, dass der Server Benutzerautorisierungsinformationen auf dem Server speichert und verwaltet, wodurch Berechtigungen Teil des Anwendungsstatus werden
• Dies bedeutet, dass der Client nur eine "Authentifizierungs-ID" behalten muss und der Server Authentifizierungsdetails aus seiner Datenbank lesen kann
• Dies bedeutet, dass der Server einen Pool aktiver Authentifizierungen (angemeldete Benutzer) verwaltet und diese Informationen für jede Anforderung abfragt
• "Statuslose Autorisierung" bedeutet, dass der Server keine Benutzerauthentifizierungsinformationen speichert und verwaltet, einfach nicht weiß, welche Benutzer angemeldet sind, und sich darauf verlässt, dass der Client Authentifizierungsinformationen erstellt
• Der Client speichert vollständige Authentifizierungsinformationen wie Ihre Person (Benutzer-ID) und möglicherweise Berechtigungen, Ablaufzeit usw. Dies ist mehr als nur eine Authentifizierungs-ID, sodass ihm ein neues Namens- Token zugewiesen wird
• Offensichtlich kann dem Client nicht vertraut werden, daher werden Authentifizierungsdaten zusammen mit einer Signatur gespeichert, die von generiert wird hash(data + secret key), wobei der geheime Schlüssel nur dem Server bekannt ist, sodass die Integrität der Token-Daten überprüft werden kann
• Beachten Sie, dass der Token-Mechanismus lediglich die Integrität, nicht aber die Vertraulichkeit gewährleistet. Der Client muss dies implementieren
• Dies bedeutet auch, dass der Client für jede Anforderung ein vollständiges Token senden muss, wodurch zusätzliche Bandbreite entsteht

MECHANISMUSVERGLEICH

• "Cookie" ist nur eine Kopfzeile, jedoch mit einigen vorinstallierten Vorgängen in Browsern
• Das Cookie kann vom Server gesetzt und vom Client automatisch gespeichert werden und wird automatisch für dieselbe Domain gesendet
• Cookies können so markiert werden, httpOnlydass sie den JavaScript-Zugriff des Clients verhindern
• Vorinstallierte Vorgänge sind möglicherweise nicht auf anderen Plattformen als Browsern (z. B. Mobilgeräten) verfügbar, was zu zusätzlichen Anstrengungen führen kann
• "Benutzerdefinierte Header" sind nur benutzerdefinierte Header ohne vorinstallierte Vorgänge
• Der Client ist dafür verantwortlich, den benutzerdefinierten Header-Bereich für jede Anforderung zu empfangen, zu speichern, zu sichern, zu senden und zu aktualisieren. Dies kann dazu beitragen, das Einbetten einfacher böswilliger URLs zu verhindern

ZUSAMMENFASSEN

• Es gibt keine Magie, der Authentifizierungsstatus muss irgendwo gespeichert werden, entweder auf dem Server oder auf dem Client
• Sie können Stateful / Stateless entweder mit Cookies oder anderen benutzerdefinierten Headern implementieren
• Wenn Leute über diese Dinge sprechen, ist ihre Standard-Denkweise meistens: zustandslos = Token + benutzerdefinierter Header, stateful = Auth ID + Cookie; Dies sind NICHT die einzig möglichen Optionen
• Sie haben Vor- und Nachteile, aber selbst für verschlüsselte Token sollten Sie keine vertraulichen Informationen speichern

Verknüpfung

Ich glaube, dass es hier einige Verwirrung gibt. Der wesentliche Unterschied zwischen der Cookie-basierten Authentifizierung und dem, was jetzt mit HTML5 Web Storage möglich ist, besteht darin, dass Browser so aufgebaut sind, dass sie Cookie-Daten senden, wenn sie Ressourcen von der Domäne anfordern, die sie festgelegt hat. Sie können dies nicht verhindern, ohne Cookies auszuschalten. Browser senden keine Daten aus dem Webspeicher, es sei denn, der Code auf der Seite sendet sie . Und Seiten können nur auf Daten zugreifen, die sie gespeichert haben, nicht auf Daten, die von anderen Seiten gespeichert wurden.

Ein Nutzer, der sich Sorgen darüber macht, wie seine Cookie-Daten von Google oder Facebook verwendet werden könnten, kann Cookies deaktivieren. Sie haben jedoch weniger Grund, den Webspeicher zu deaktivieren (bis die Werbetreibenden einen Weg finden, dies ebenfalls zu nutzen).

Das ist also der Unterschied zwischen Cookie-basierten und Token-basierten, letzterer verwendet Web Storage.

Die Token-basierte Authentifizierung ist zustandslos. Der Server muss keine Benutzerinformationen in der Sitzung speichern. Auf diese Weise können Anwendungen skaliert werden, ohne sich Gedanken darüber machen zu müssen, wo sich der Benutzer angemeldet hat. Es besteht eine Affinität des Webserver-Frameworks zu Cookies, während dies bei Token-basierten Problemen kein Problem darstellt. Das gleiche Token kann also zum Abrufen einer sicheren Ressource aus einer anderen Domäne als der von uns angemeldeten verwendet werden, wodurch eine weitere UID / PWD-Authentifizierung vermieden wird.

Sehr guter Artikel hier:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Verwenden Sie Token, wenn ...

Föderation ist erwünscht. Sie möchten beispielsweise einen Anbieter (Token Dispensor) als Token-Aussteller verwenden und dann Ihren API-Server als Token-Validator verwenden. Eine App kann sich bei Token Dispensor authentifizieren, ein Token empfangen und dieses Token dann Ihrem API-Server zur Überprüfung vorlegen. (Gleiches gilt für Google Sign-In. Oder Paypal. Oder Salesforce.com. Usw.)

Asynchronität ist erforderlich. Sie möchten beispielsweise, dass der Client eine Anfrage sendet und diese Anfrage dann irgendwo speichert, damit sie "später" von einem separaten System bearbeitet werden kann. Dieses separate System hat keine synchrone Verbindung zum Client und möglicherweise keine direkte Verbindung zu einer zentralen Token-Apotheke. Ein JWT kann vom asynchronen Verarbeitungssystem gelesen werden, um zu bestimmen, ob das Workitem zu einem späteren Zeitpunkt erfüllt werden kann und sollte. Dies hängt in gewisser Weise mit der obigen Idee der Föderation zusammen. Seien Sie hier jedoch vorsichtig: JWT läuft ab. Wenn die Warteschlange mit dem Arbeitselement nicht innerhalb der Lebensdauer des JWT verarbeitet wird, sollten die Ansprüche nicht mehr vertrauenswürdig sein.

Cient Signed Anfrage ist erforderlich. Hier wird die Anforderung vom Client mit seinem privaten Schlüssel signiert und der Server wird mit dem bereits registrierten öffentlichen Schlüssel des Clients validiert.

Einer der Hauptunterschiede besteht darin, dass Cookies der gleichen Ursprungsrichtlinie unterliegen, Token jedoch nicht. Dies erzeugt alle Arten von Downstream-Effekten.

Da Cookies nur an und von einem bestimmten Host gesendet werden, muss dieser Host die Last der Authentifizierung des Benutzers tragen und der Benutzer muss ein Konto mit Sicherheitsdaten bei diesem Host erstellen, um überprüfbar zu sein.

Tokens hingegen werden ausgestellt und unterliegen nicht derselben Ursprungsrichtlinie. Der Emittent kann buchstäblich jeder sein, und es ist Sache des Gastgebers, zu entscheiden, welchen Emittenten er vertrauen soll. Ein Emittent wie Google und Facebook ist in der Regel sehr vertrauenswürdig, sodass ein Host die Authentifizierungslast des Benutzers (einschließlich der Speicherung aller Benutzersicherheitsdaten) auf eine andere Partei verlagern kann und der Benutzer seine persönlichen Daten unter einem bestimmten Emittenten konsolidieren kann und sich nicht an a erinnern muss Eine Reihe verschiedener Passwörter für jeden Host, mit dem sie interagieren.

Dies ermöglicht Single-Sign-On-Szenarien, die die allgemeine Reibung in der Benutzererfahrung verringern. Theoretisch wird das Web auch sicherer, wenn spezialisierte Identitätsanbieter Authentifizierungsdienste bereitstellen, anstatt dass jede ma- und pa-Website ihre eigenen, wahrscheinlich halbgebackenen Authentifizierungssysteme hochfährt. Und da diese Anbieter auftauchen, steigen die Kosten für die Bereitstellung sicherer Webressourcen für selbst sehr grundlegende Ressourcentendenzen gegen Null.

Im Allgemeinen reduzieren Token die Reibung und die Kosten, die mit der Bereitstellung der Authentifizierung verbunden sind, und verlagern die Belastung durch die verschiedenen Aspekte eines sicheren Webs auf zentralisierte Parteien, die Sicherheitssysteme besser implementieren und warten können.