Cookie, Session, JWT und Token gründlich verstehen (dringend empfohlen)

Einführung: http ist ein zustandsloses Protokoll? Wie man es löst?

Zustandslos bedeutet, dass das Protokoll keine Speicherkapazität für die Transaktionsverarbeitung hat . Der fehlende Zustand bedeutet, dass, wenn frühere Informationen für die nachfolgende Verarbeitung erforderlich sind, diese erneut übertragen werden müssen, was möglicherweise zu einer erhöhten Datenmenge führt, die pro Verbindung übertragen wird. Die Zustandslosigkeit von HTTP behindert die Implementierung dieser Anwendungen erheblich, schließlich muss die Interaktion ein Bindeglied zwischen Vergangenheit und Zukunft sein, und ein einfaches Warenkorbprogramm muss auch wissen, welche Produkte der Benutzer zuvor ausgewählt hat. Als Ergebnis entstanden zwei Techniken zum Aufrechterhalten des Zustands der HTTP-Verbindung, eine ist Cookie und die andere ist Session.

1. Cookies und Sitzungen

Das Cookie kann verwendet werden, um einige vom Server zurückgegebene Benutzerinformationen zu speichern, und jede Anfrage trägt diese Cookies. Wenn der Server die Informationen im Cookie aus dem Anforderungsheader erhält, kann er die Quelle der Anforderung identifizieren und http wird zustandsbehaftet.

Da die Lösung zum Beibehalten des Zustands auf der Serverseite auch eine Kennung auf der Clientseite speichern muss, muss der Sitzungsmechanismus möglicherweise den Cookie-Mechanismus verwenden, um den Zweck des Speicherns der Kennung zu erreichen. Cookies sind nicht sehr sicher. Andere können das lokal gespeicherte Cookie analysieren und eine Cookie-Täuschung durchführen. Aus Sicherheitsgründen sollte die Sitzung verwendet werden, und die Sitzung wird für einen bestimmten Zeitraum auf dem Server gespeichert. Wenn die Anzahl der Besuche zunimmt, wird die Leistung Ihres Servers beansprucht.Um die Leistung des Servers zu reduzieren, sollten Sie Cookies verwenden.

1.1 Hinweise zu Cookies:

1.Cookies werden clientseitig (browserseitig) gespeichert, also ist es nicht sicher und kann von Menschen gelöscht werden. Ein Cookie ist ein kleines Datenelement, das der Server an den Browser des Benutzers sendet und lokal speichert. Es wird übertragen und an den Server gesendet, wenn der Browser das nächste Mal eine Anfrage an denselben Server stellt.
2,Cookies haben Ablaufzeiteinstellungen. Wenn die Ablaufzeit nicht gesetzt ist, stellt das Cookie die Sitzungszeit des aktuellen Browsers dar. Wenn der Browser geschlossen wird, existiert das Cookie nicht. Wenn es eine Ablaufzeit gibt, wird das Cookie auf der Festplatte gespeichert und das Schließen des Browsers hat keinen Einfluss auf das Cookie. Beim nächsten Öffnen des Browsers ist das Cookie noch vorhanden
3.Cookies können vom Benutzer deaktiviert werden
4.Cookies haben eine Größenbeschränkung, die maximale Anzahl von Cookies, die ein Browser erstellen kann, beträgt 300, und jedes darf 4 KB nicht überschreiten , und die Gesamtzahl von Cookies, die von jeder Website gesetzt werden können, darf 20 nicht überschreiten.
5.Cookies sind nicht domänenübergreifend: Jedes Cookie wird an einen einzelnen Domainnamen gebunden, der nicht unter anderen Domainnamen erhalten und verwendet werden kann. Die gemeinsame Nutzung ist zwischen dem Domainnamen der ersten Ebene und dem Domainnamen der zweiten Ebene (in Abhängigkeit von der Domain) zulässig.

1.2 Wichtige Eigenschaften von Cookies

Name des Anwesens beschreiben
Zeichenfolgenname _ Der Name dieses Cookies . Sobald das Cookie erstellt wurde, kann der Name nicht mehr geändert werden, es muss ein Zeichenfolgentyp sein
Objektwert Der Wert dieses Cookies . Wenn der Wert ein Unicode-Zeichen ist, muss es sich um die Zeichencodierung handeln. Wenn es sich bei dem Wert um Binärdaten handelt, müssen Sie die BASE64-Codierung verwenden
int maxAge Die Ablaufzeit des Cookies in Sekunden. Wenn positiv, läuft das Cookie nach maxAge Sekunden ab. Wenn es sich um eine negative Zahl handelt, handelt es sich bei dem Cookie um ein temporäres Cookie, das nach dem Schließen des Browsers ungültig wird, und der Browser speichert das Cookie in keiner Form. Wenn es 0 ist, bedeutet dies, dass das Cookie gelöscht werden soll. Standardmäßig –1.besser als verfällt
int verfällt Legen Sie die Cookie-Ablaufzeit fest, das Cookie läuft nach einer bestimmten eingestellten Zeit ab.
boolesch sicher Ob das Cookie nur über ein sicheres Protokoll übertragen wird . Sicherheitsprotokoll. Zu den Sicherheitsprotokollen gehören HTTPS, SSL usw., die Daten verschlüsseln, bevor sie im Netzwerk übertragen werden. Standardmäßig falsch.Wenn der sichere Wert wahr ist,Cookies sind in HTTP ungültig, nur in HTTPS gültig
String-Pfad Der Nutzungspfad dieses Cookies . Wenn es auf „/love/“ gesetzt ist, können nur Programme, deren Kontextpfad „/love“ ist, auf das Cookie zugreifen. Wenn es auf "/" gesetzt ist, kann der Kontextpfad unter diesem Domänennamen auf das Cookie zugreifen. Beachten Sie, dass das letzte Zeichen "/" sein muss.
String-Domäne Legt fest, für welche Domain das Cookie verwendet wird . Standard ist der aktuelle Domänenname
int-Version Die von diesem Cookie verwendete Versionsnummer . 0 bedeutet, der Cookie-Spezifikation von Netscape zu folgen, 1 bedeutet, der RFC 2109-Spezifikation von W3C zu folgen
Nur HTTP Das Cookie kann nicht von js gelesen werden , aber das Cookie kann immer noch manuell in der Anwendung geändert werden, sodass es XSS-Angriffe nur bis zu einem gewissen Grad verhindert und nicht absolut sicher ist

1.3 Sitzungsnotizen:

1.Die Sitzung dient zum Speichern von Benutzerinformationen auf dem Server, Wenn immer mehr Benutzer auf den Server zugreifen, werden immer mehr Sitzungen auf dem Server stattfinden, und die Sitzung wird den Server belasten und die Last des Servers beeinträchtigen. Wenn der Inhalt der Sitzung zu komplex ist, Wenn eine große Anzahl von Clients auf den Server zugreift, kann dies auch zu Speichermangel führen.
2,Wenn die Benutzerinformationen verloren gehen oder der Benutzer nicht auf diesen Server zugreift, geht die Datenbank verloren.. Das ist sein Nachteil. Nun gibt es einige Technologien, wie Session Sharing, Iphash, Session Persistence etc., die ebenfalls die oben genannten Probleme lösen können.
3.Wenn Cookies deaktiviert sind, werden auch Sitzungen deaktiviert. Ein Cookie ist nur eine Möglichkeit, eine Sitzung zu implementieren. Obwohl dies die am häufigsten verwendete Methode ist, ist sie nicht die einzige. Es gibt andere Möglichkeiten zum Speichern nach dem Deaktivieren von Cookies, z. B. das Einfügen in die URL.
4. Die Session wird basierend auf Cookies implementiert, die Session wird serverseitig gespeichert und die SessionId wird im Cookie des Clients gespeichert
Bildbeschreibung hier einfügen
Gemäß dem obigen Prozess können wir sehen, dass SessionID eine Brücke ist, die Cookie und Session verbindet , und die meisten Systeme überprüfen auch den Anmeldestatus des Benutzers auf der Grundlage dieses Prinzips. Das größte Problem bei diesem Modell ist jedoch, dass es ohne eine verteilte Architektur keine horizontale Skalierung unterstützen kann . Wenn Sie einen Server verwenden, ist dieser Modus völlig in Ordnung. Wenn es sich jedoch um einen Servercluster oder eine dienstorientierte domänenübergreifende Architektur handelt, wird eine einheitliche Sitzungsdatenbankbibliothek benötigt, um Sitzungsdaten zu speichern und gemeinsam zu nutzen, damit jeder Server unter Lastausgleich Benutzeridentitäten korrekt authentifizieren kann.
Um dieses Problem zu lösen, können wir Token verwenden, siehe die Erklärung von Token unten

1.4 Der Unterschied zwischen Cookie und Sitzung:

Lassen Sie uns basierend auf der obigen Erklärung abschließend ihre allgemeinen Unterschiede zusammenfassen:
Sicherheit: Sitzung ist sicherer als Cookie, Sitzung wird auf der Serverseite gespeichert und Cookie wird auf der Clientseite gespeichert.
Die Arten von Zugriffswerten sind unterschiedlich : Cookie unterstützt nur das Speichern von String-Daten, und Session kann jeden Datentyp speichern.
Unterschiedliche Gültigkeitsdauer: Cookies können so eingestellt werden , dass sie lange aufbewahrt werden, wie z Sitzungszeitüberschreitung.
Die Speichergröße ist unterschiedlich: Die von einem einzelnen Cookie gespeicherten Daten können 4K nicht überschreiten, und die Sitzung kann viel mehr Daten speichern als ein Cookie, aber wenn es zu viele Besuche gibt, werden zu viele Serverressourcen beansprucht.

Hinweis:
Die meisten von ihnen sind jetzt Session + Cookie, aber nur Session ohne Cookie oder nur Cookie ohne Session kann theoretisch den Session-Status aufrechterhalten. In der Praxis wird es jedoch aus verschiedenen Gründen im Allgemeinen nicht allein verwendet.Wenn nur ein Cookie ohne Sitzung verwendet wird, werden alle Kontoinformationen auf der Clientseite gespeichert.Nachdem sie gekapert wurden, werden alle Informationen durchgesickert. Und die Menge an Client-Daten wird größer, und die Menge an Daten, die über das Netzwerk übertragen werden, wird ebenfalls größer.
Bei der Verwendung von Session muss nur eine ID auf der Clientseite gespeichert werden, tatsächlich wird eine große Datenmenge auf der Serverseite gespeichert. Wenn alle Cookies verwendet werden, hat der Client bei großen Datenmengen nicht so viel Platz.
Kurz gesagt, die Sitzung ist wie eine Benutzerinformationstabelle, die die Informationen des Benutzers enthält (Name, Status usw.) Das Cookie ist der Benutzerpass

2. Zeichen (Token)

Token ist, wie der Name schon sagt, ein Token, ein Zertifikat und ein Schlüssel.Nur mit diesem Schlüssel können Sie die Tür öffnen . Token werden im Allgemeinen vom Server generiert, beispielsweise einem Websystem. Wenn sich der Benutzer anmeldet, wird nach der Überprüfung des Benutzernamens und des Passworts durch den Server ein Token generiert, und dann wird das Token an den Client zurückgegeben, und der Client wird dies tun Speichern Sie das Token (in den HTTP-Header eingefügt), alle nachfolgenden Anforderungen tragen dieses Token. Der Server bestimmt, ob das aktuelle Token existiert und abgelaufen ist. Wenn das Token nicht existiert oder abläuft, wird die Anfrage abgelehnt.

Die Zusammensetzung eines einfachen Tokens: uid (eindeutige Identität des Benutzers), time (Zeitstempel der aktuellen Zeit), sign (Signatur, die ersten paar Ziffern des Tokens werden durch einen Hash-Algorithmus zu einer hexadezimalen Zeichenkette bestimmter Länge komprimiert)

2.1 Token-Vorteile

1.Das Token wird vollständig von der Anwendung verwaltet, sodass die Same-Origin-Richtlinie vermieden werden kann
2.Sicherheit. Token kann CSRF-Angriffe vermeiden (da Cookies nicht benötigt werden)
CSRF-Angriffe (Cross-Site Request Forgery) : Angreifer stehlen Ihre Identität und senden böswillige Anfragen in Ihrem Namen . Zu den Dingen, die CSRF tun kann, gehören: E-Mails in Ihrem Namen senden, Nachrichten senden, Ihr Konto stehlen, sogar Waren kaufen, virtuelle Währungen übertragen ... Zu den verursachten Problemen gehören: Verlust der Privatsphäre und Sicherheit von Eigentum. (Wer wissen möchte, was der CSRF-Angriff ist, kann im Kommentarbereich darüber diskutieren)
3.Zustandslos und skalierbar, die von mehreren Diensten gemeinsam genutzt werden kann
4.Multi-Plattform-Cross-Domain: Wenn CORS (Cross-Origin Resource Sharing) Anwendungen und Dienste erweitert, müssen verschiedene Geräte und Anwendungen beteiligt sein. Solange der Benutzer über ein authentifiziertes Token verfügt, können Daten und Ressourcen auf jeder Domäne angefordert werden.

2.2 Token-Authentifizierungsprozess

Bildbeschreibung hier einfügen

3. Token-Authentifizierungsschema basierend auf JWT

Beim Erstellen eines Tokens können wir einige Optionen festlegen. Aber die Standardverwendung wird in JSON Web Tokens verkürztJWTreflektieren.
JSON Web Token (JWT) ist derzeit die beliebteste domänenübergreifende Authentifizierungslösung.

3.1 JWT-Komponenten

Ein JSON Web Tokens-Token besteht aus drei Teilen in kompakter Form, die durch Punkte (. ) getrennt sind:

Header: Header
Nutzlast: Nutzlast
Signatur: Signatur

Bildbeschreibung hier einfügen
Das Objekt ist eine sehr lange Zeichenfolge, und die Zeichen werden durch das Trennzeichen „.“ in drei Teilzeichenfolgen unterteilt.
Jeder Teilstring stellt einen Funktionsblock dar, und es gibt insgesamt drei Teile: JWT-Header, Payload und Signatur

3.1.1 Kopfzeile: Kopfzeile

Der Header besteht normalerweise aus zwei Teilen: dem Typ des Tokens (z. B. JWT) und dem verwendeten Signaturalgorithmus, z. B. HMAC SHA256 oder RSA.
Z.B:

 此JSON被Base64Url编码以形成JWT的第一部分。
{
    
    
"alg": "HS256",表示签名使用的算法,默认为HMAC SHA256(写为HS256)
"typ": "JWT"表示令牌的类型,JWT令牌统一写为JWT
}

3.1.2 Nutzlast: Nutzlast

Der Payload-Teil ist der Hauptinhaltsteil des JWT und auch ein JSON-Objekt, das die zu übergebenden Daten enthält. JWT gibt sieben Standardfelder
zur Auswahl an.

iss: Aussteller
exp: Ablaufzeit
sub: Betreff
aud: Benutzer
nbf: bis dahin nicht verfügbar
Iat: Ausstellungszeit
jti: JWT-ID zur Identifizierung dieses JWT

Zusätzlich zu den oben genannten Standardfeldern können wir auch private Felder anpassen, eine Beispielnutzlast kann sein:

{
    
    
"sub": "9876543210",
"name": "Mr Fen",
"admin": true
请注意,默认情况下JWT是未加密的,任何人都可以解读其内容,因此不要构建隐私信息字段,存放保密信息,以防止信息泄露。
}

3.1.3 Payload: Signatur

Um den signierten Teil zu erstellen, müssen Sie den codierten Header, die codierte Nutzlast, den Schlüssel und den im Header angegebenen Algorithmus abrufen und signieren.
Wenn Sie beispielsweise den HMAC SHA256-Algorithmus verwenden, wird die Signatur folgendermaßen erstellt:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)

3.2 Wann sollte JWT verwendet werden?

1. Authentifizierung, das häufigste Szenario für die Verwendung von JWT . Sobald der Benutzer angemeldet ist, enthält jede nachfolgende Anfrage das JWT, sodass der Benutzer auf Routen, Dienste und Ressourcen zugreifen kann, die von diesem Token zugelassen werden. Single Sign-On ist eine Funktion , die heute mit JWT weit verbreitet ist, da sie wenig Overhead hat und problemlos über verschiedene Domänen hinweg verwendet werden kann.
2. Informationsaustausch, JWT-Token sind eine großartige Möglichkeit, Informationen sicher zwischen Parteien zu übertragen . Da das JWT signiert werden kann (z. B. mit einem öffentlichen/privaten Schlüsselpaar), können Sie sicher sein, dass Sie der Absender sind. Da die Signatur anhand des Headers und der Payload berechnet wird, können Sie auch überprüfen, ob der Inhalt nicht manipuliert wurde.

3.3 Welche Beziehung besteht zwischen JWT und Token?

Ein Token ist eine nach bestimmten Regeln generierte Zeichenfolge und enthält Benutzerinformationen.
Im Allgemeinen verwenden wir das Standardnutzungs-JWT.
JWT soll uns Regeln vorgeben Mit JWT können wir Strings generieren, die Benutzerinformationen enthalten.

Supongo que te gusta

Origin blog.csdn.net/weixin_46015018/article/details/122667394
Recomendado
Clasificación