Ein umfassender Überblick über Cookies, Sitzungen und Token in einem Artikel

Entwicklungsgeschichte

1. Vor langer Zeit war das Web im Grunde nur das Durchsuchen von Dokumenten Beim Durchsuchen muss als Server nicht aufgezeichnet werden, wer welche Dokumente in einem bestimmten Zeitraum durchsucht hat. Bei jeder Anforderung handelt es sich um eine Anforderung und eine Antwort. Insbesondere muss ich mich nicht merken, wer Ich habe gerade eine HTTP-Anfrage gesendet. Beide Anfragen sind für mich neu. Es ist eine sehr aufregende Zeit.

2. Mit dem Aufkommen interaktiver Webanwendungen wie Online-Shopping-Websites, Websites, die eine Anmeldung erfordern usw., stehen wir jedoch sofort vor einem Problem: Um Sitzungen zu verwalten, müssen wir uns daran erinnern, wer sich anmeldet Wer Artikel in den Warenkorb legt, d ID (Sitzungs-ID), um es ganz klar auszudrücken, es ist eine zufällige Zeichenfolge. Jedes Mal, wenn Sie eine HTTP-Anfrage senden, senden Sie diese Zeichenfolge mit, damit ich sie unterscheiden kann.

3. Alle sind sehr zufrieden, aber der Server ist nicht zufrieden. Jeder muss nur seine eigene Sitzungs-ID speichern, und der Server muss die Sitzungs-ID aller speichern! Wenn es zu viele Zugriffsserver gibt, werden es Tausende oder sogar Hunderttausende sein.

Dies ist ein enormer Overhead für den Server und schränkt die Erweiterungsmöglichkeiten des Servers erheblich ein. Wenn ich beispielsweise zwei Maschinen verwende, um einen Cluster zu bilden, und Little F sich über Maschine A beim System anmeldet, ist die Sitzungs-ID Was passiert, wenn die nächste Anfrage von Little F an Maschine B weitergeleitet wird? Maschine B hat nicht die Sitzungs-ID des kleinen F.

Manchmal wird ein kleiner Trick angewendet: Session Sticky, was bedeutet, dass die Anfrage von Little F immer an Maschine A hängen bleibt, aber das funktioniert nicht. Wenn Maschine A aufhängt, muss sie an Maschine weitergeleitet werden B. .

Dann müssen wir die Sitzungs-ID zwischen den beiden Maschinen kopieren, ist fast anstrengend.

Später hat sich jemand namens Memcached einen Trick ausgedacht: Sitzungs-IDs zentral an einem Ort speichern, und alle Maschinen greifen auf die Daten an diesem Ort zu Das Kopieren ist nicht nötig, aber es erhöht die Möglichkeit eines Single Point of Failure. Wenn der für die Sitzung verantwortliche Computer aufhängt, müssen sich alle erneut anmelden und werden wahrscheinlich zu Tode gescholten.

Ich habe auch versucht, diese einzelne Maschine in einen Cluster zu packen, um die Zuverlässigkeit zu erhöhen, aber egal was passiert, diese kleine Sitzung ist eine schwere Belastung für mich.

4. Warum sollte ich diese abscheuliche Sitzung speichern?

Aber wenn diese Sitzungs-IDs nicht gespeichert werden, wie kann ich dann überprüfen, ob die mir vom Client gesendete Sitzungs-ID tatsächlich von mir generiert wurde? Wenn wir dies nicht überprüfen, wissen wir nicht, ob es sich um legitime angemeldete Benutzer handelt, und diejenigen mit bösen Absichten können Sitzungs-IDs fälschen und tun, was sie wollen.

Nun, der entscheidende Punkt ist übrigens die Verifizierung!

Zum Beispiel hat sich Little F am System angemeldet und ich sende ihm ein Token, das die Benutzer-ID von Little F enthält. Wenn Little F das nächste Mal erneut Zugriff auf mich anfordert, kann dieses Token übermittelt werden über den HTTP-Header.

Aber es gibt keinen wesentlichen Unterschied zwischen dieser und der Sitzungs-ID. Jeder kann sie fälschen, also muss ich mir eine Möglichkeit überlegen, andere daran zu hindern, sie zu fälschen.

Dann erstelle ich eine Signatur für die Daten. Ich verwende zum Beispiel den HMAC-SHA256-Algorithmus, füge einen Schlüssel hinzu, den nur ich kenne, erstelle eine Signatur für die Daten und verwende diese Signatur und die Daten als Token Da der Schlüssel anderen unbekannt ist, kann der Token nicht gefälscht werden.

Verwandte Empfehlungen: „Python-Video-Tutorial“

Ich werde diesen Token nicht speichern, wenn mir der kleine F diesen Token schickt Wenn ich vorbeikomme, verwende ich denselben HMAC-SHA256-Algorithmus und denselben Schlüssel, um die Signatur erneut für die Daten zu berechnen und sie mit der Signatur im Token zu vergleichen. Wenn sie identisch sind, weiß ich, dass Xiao F sich angemeldet hat und kann ich direkt die Benutzer-ID von Little F erhalten. Wenn sie nicht identisch ist, muss der Datenteil manipuliert worden sein. Ich sage dem Absender: Entschuldigung, es gibt keine Authentifizierung.

Die Daten im Token werden im Klartext gespeichert (ich verwende zwar Base64 zur Kodierung, aber das ist keine Verschlüsselung), sie können also trotzdem von anderen gesehen werden Ich kann darin keine sensiblen Informationen wie Passwörter speichern.

Wenn der Token einer Person von anderen gestohlen wird, kann ich natürlich auch nichts dagegen tun, dass der Dieb ein legitimer Benutzer ist. Dies ist tatsächlich dasselbe, als würde die Sitzungs-ID einer Person von anderen gestohlen.

Auf diese Weise speichere ich nicht die Sitzungs-ID, sondern generiere nur das Token und verifiziere dann das Token, um meinen Sitzungsspeicherplatz zu erhalten.

Die Belastung durch die Sitzungs-ID wurde verringert. Man kann sagen, dass ich mir keine Sorgen mehr machen muss, wenn die Anzahl der Benutzerbesuche zunimmt . Dieses staatenlose Gefühl tut so gut!

Cookie

Cookie ist eine sehr spezifische Sache. Es handelt sich um eine Art von Daten, die dauerhaft im Browser gespeichert werden können durch die Speicherfunktion.

Cookie wird vom Server generiert und an den Browser gesendet. Der Browser speichert das Cookie in einer Textdatei in einem bestimmten Verzeichnis. Das Cookie wird beim nächsten Besuch derselben Website an den Server gesendet angefordert. Da Cookies auf dem Client gespeichert werden, hat der Browser einige Einschränkungen hinzugefügt, um sicherzustellen, dass Cookies nicht in böswilliger Absicht verwendet werden und nicht zu viel Speicherplatz belegen, sodass die Anzahl der Cookies für jede Domäne begrenzt ist.

Sitzung

Sitzung bedeutet wörtlich Sitzung. Das ist ähnlich wie wenn man mit jemandem spricht. Woher weiß man, dass die Person, mit der man spricht, Zhang San ist und nicht Li Si? Die Gegenpartei muss bestimmte Merkmale (z. B. Aussehen) aufweisen, die darauf hinweisen, dass es sich bei ihr um Zhang San handelt.

Sitzung ist ähnlich. Der Server muss wissen, wer gerade die Anfrage an sich selbst sendet. Um diese Unterscheidung zu treffen, weist der Server jedem Client eine andere „Identitätskennung“ zu. Jedes Mal, wenn der Client eine Anfrage an den Server sendet, übermittelt er diese „Identitätskennung“ und der Server erkennt die Anfrage kommt von Who. Es gibt viele Möglichkeiten, wie der Client diese „Identität“ speichert. Bei Browser-Clients verwendet jeder standardmäßig Cookies.

Der Server verwendet die Sitzung, um die Informationen des Benutzers vorübergehend auf dem Server zu speichern. Die Sitzung wird zerstört, nachdem der Benutzer die Website verlässt. Diese Methode zum Speichern von Benutzerinformationen ist sicherer als Cookies, die Sitzung weist jedoch einen Fehler auf: Wenn der Webserver über einen Lastausgleich verfügt, geht die Sitzung verloren, wenn die nächste Vorgangsanforderung an einen anderen Server geht.

Token

Tokenbasierte Authentifizierung ist überall im Webbereich zu sehen. In den meisten Internetunternehmen, die Web-APIs verwenden, sind Token die beste Möglichkeit, die Authentifizierung für mehrere Benutzer durchzuführen.

Die folgenden Funktionen ermöglichen Ihnen die Verwendung der tokenbasierten Authentifizierung in Ihrem Programm:

(1) Zustandslos und skalierbar

(2) Unterstützung mobiler Geräte

(3) Programmübergreifende Aufrufe

(4) Sicherheit

Die großen Jungs, die tokenbasierte Authentifizierung verwenden, die meisten APIs und Webanwendungen, die Sie gesehen haben, verwenden alle Token. Zum Beispiel Facebook, Twitter, Google+, GitHub usw.

Der Ursprung des Tokens

Bevor Sie die Prinzipien und Vorteile der tokenbasierten Authentifizierung vorstellen, können Sie sich auch ansehen, wie die vorherige Authentifizierung durchgeführt wurde.

Serverbasierte Überprüfung

Wir alle wissen, dass das HTTP-Protokoll zustandslos ist. Diese Zustandslosigkeit bedeutet, dass das Programm jede Anfrage überprüfen muss, um die Identität des Clients zu identifizieren.

Zuvor identifizierte das Programm die Anfrage anhand der auf dem Server gespeicherten Anmeldeinformationen. Diese Methode wird im Allgemeinen durch das Speichern einer Sitzung erreicht.

Mit dem Aufkommen des Webs, von Anwendungen und mobilen Endgeräten hat diese Überprüfungsmethode nach und nach Probleme aufgedeckt. Vor allem, wenn es um Skalierbarkeit geht.

Einige Probleme werden aufgrund der Serverauthentifizierungsmethode aufgedeckt

(1) Sitzung: Jedes Mal, wenn ein authentifizierter Benutzer eine Anfrage initiiert, muss der Server einen Datensatz zum Speichern erstellen Information. Wenn immer mehr Benutzer Anfragen senden, steigt der Speicheraufwand weiter an.

(2) Skalierbarkeit: Die Verwendung von Session zum Speichern von Anmeldeinformationen im Speicher des Servers bringt Skalierbarkeitsprobleme mit sich.

(3) CORS (Cross-Origin Resource Sharing): Wenn wir Daten auf mehreren Mobilgeräten nutzen müssen, kann die gemeinsame Nutzung domänenübergreifender Ressourcen Kopfschmerzen bereiten. Wenn Sie Ajax zum Crawlen von Ressourcen aus einer anderen Domäne verwenden, sind Anforderungen möglicherweise verboten.

(4) CSRF (Cross-Site Request Forgery): Wenn Benutzer Bank-Websites besuchen, sind sie anfällig für Cross-Site Request Forgery-Angriffe und können für den Zugriff auf andere Websites ausgenutzt werden.

Unter diesen Themen ist die Skalierbarkeit das wichtigste. Deshalb müssen wir eine effektivere Methode finden.

Tokenbasiertes Authentifizierungsprinzip

Tokenbasierte Authentifizierung ist zustandslos und wir speichern keine Benutzerinformationen auf dem Server oder in der Sitzung.

Dieses Konzept löst viele Probleme beim Speichern von Informationen auf der Serverseite:

NoSession bedeutet, dass Ihr Programm nach Bedarf Maschinen hinzufügen oder entfernen kann, ohne sich Gedanken darüber machen zu müssen, ob der Benutzer angemeldet ist.

Der Prozess der tokenbasierten Authentifizierung ist wie folgt:

(1) Der Benutzer sendet eine Anfrage mit Benutzername und Passwort.

(2) Programmüberprüfung.

(3) Das Programm gibt ein signiertes Token an den Client zurück.

(4) Der Client speichert das Token und verwendet es für jede Anfrage.

(5) Der Server überprüft das Token und gibt Daten zurück.

Jede Anfrage erfordert einen Token. Das Token sollte im HTTP-Header gesendet werden, um sicherzustellen, dass HTTP-Anfragen zustandslos sind. Wir legen außerdem die Servereigenschaft Access-Control-Allow-Origin:* fest, damit der Server Anfragen von allen Domänen annehmen kann.

Es ist zu beachten, dass, wenn der ACAO-Header mit * markiert (bezeichnend) ist, Zertifikate wie HTTP-Authentifizierung, Client-SSL-Zertifikat und Cookies nicht enthalten sein dürfen.

Implementierungsideen:

(1) Benutzeranmeldungsüberprüfung Nach erfolgreicher Überprüfung wird das Token an den Client zurückgegeben.

(2) Der Kunde speichert die Daten nach Erhalt auf dem Kunden.

(3) Der Client überträgt das Token jedes Mal an den Server, wenn er auf die API zugreift.

(4) Die Serverseite verwendet die Filterfilterüberprüfung. Bei erfolgreicher Verifizierung werden die Anfragedaten zurückgegeben, bei fehlgeschlagener Verifizierung wird ein Fehlercode zurückgegeben. Nachdem wir die Informationen im Programm authentifiziert und das Token erhalten haben, können wir mit diesem Token viele Dinge tun. Wir können sogar ein berechtigungsbasiertes Token erstellen und es an Anwendungen von Drittanbietern weitergeben, die unsere Daten abrufen können (nur mit dem spezifischen Token, das wir zulassen).

Vorteile von Tokens

Zustandslos und skalierbar

Auf dem Client gespeicherte Token. Es ist zustandslos und erweiterbar. Aufgrund dieser Zustandslosigkeit und der fehlenden Speicherung von Sitzungsinformationen kann der Load Balancer Benutzerinformationen von einem Dienst auf andere Server übertragen.

Wenn wir die Informationen des authentifizierten Benutzers in der Sitzung speichern, erfordert jede Anfrage, dass der Benutzer Authentifizierungsinformationen an den authentifizierten Server sendet (sogenannte Sitzungsaffinität). Wenn die Anzahl der Benutzer groß ist, kann es zu einer Überlastung kommen.

Aber beeilen Sie sich nicht. Nach der Verwendung von Token lassen sich diese Probleme leicht lösen, da die Token selbst die Verifizierungsinformationen des Benutzers enthalten.

Sicherheit

Das Senden eines Tokens anstelle eines Cookies in der Anfrage kann CSRF (Cross-Site Request Forgery) verhindern. Auch wenn ein Cookie zum Speichern von Tokens auf der Clientseite verwendet wird, ist das Cookie nur ein Speichermechanismus und wird nicht zur Authentifizierung verwendet. Wenn wir keine Informationen in der Sitzung speichern, können wir weniger Sitzungen durchführen.

Token ist zeitlich begrenzt und Benutzer müssen sich nach einer gewissen Zeit erneut verifizieren. Wir müssen nicht unbedingt warten, bis der Token automatisch abläuft. Durch den Widerruf des Tokens kann ein bestimmter Token oder eine Gruppe von Token mit derselben Authentifizierung ungültig gemacht werden.

Erweiterbarkeit

Token ermöglichen die Erstellung von Programmen, die Berechtigungen mit anderen Programmen teilen. Sie können beispielsweise ein beliebiges soziales Konto mit Ihrem eigenen Konto (Fackbook oder Twitter) verbinden. Wenn wir uns über den Dienst bei Twitter anmelden (wir werden diesen Vorgang puffern), können wir diese Puffer an den Twitter-Datenstrom anhängen (wir erlauben Buffer, in unserem Twitter-Stream zu posten).

Bei der Verwendung von Token können Sie Drittanbieteranwendungen optionale Berechtigungen erteilen. Wenn Benutzer möchten, dass eine andere Anwendung auf ihre Daten zugreift, können wir spezielle Berechtigungstoken ableiten, indem wir unsere eigene API erstellen.

Multi-Plattform-Cross-Domain

Lassen Sie uns vorab über CORS (Cross-Domain Resource Sharing) sprechen. Bei der Erweiterung von Anwendungen und Diensten müssen Sie in verschiedene Bereiche eingreifen Verschiedene Geräte und Anwendungen.

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates 
the issues that CORS brings up after we set a quick header configuration for our application.

Solange der Benutzer über ein verifiziertes Token verfügt, können Daten und Ressourcen auf jeder Domain angefordert werden.

Access-Control-Allow-Origin: *

Beim Erstellen eines Tokens basierend auf Standards können Sie einige Optionen festlegen. Wir werden es in den folgenden Artikeln ausführlicher beschreiben, aber die Standardverwendung wird sich in JSON-Web-Tokens widerspiegeln.

Für JSON Web Tokens werden die neuesten Programme und Dokumentationen bereitgestellt. Es unterstützt zahlreiche Sprachen. Das bedeutet, dass Sie Ihren Authentifizierungsmechanismus in Zukunft tatsächlich ändern können.

Das obige ist der detaillierte Inhalt vonEin umfassender Überblick über Cookies, Sitzungen und Token in einem Artikel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!