Sind Sie immer noch verwirrt über Cookie, Sitzung, Token und JWT?
coldplay.xixi
Freigeben： 2020-08-19 13:44:21
nach vorne
5748 Leute haben es durchsucht
Was ist Authentifizierung?
Laiensprachlich bedeutet es, die Identität des aktuellen Benutzers zu überprüfen und zu beweisen, dass „Sie Sie selbst sind“ (z. B. wenn Sie sich jeden Tag bei der Arbeit ein- und ausloggen, Sie müssen sich mit Ihrem Fingerabdruck anmelden, wenn Ihr Fingerabdruck mit dem im System eingegebenen Fingerabdruck übereinstimmt, ist der Check-in erfolgreich)
Authentifizierung im Internet:
Anmeldung mit Benutzername und Passwort
Anmeldelink senden an E-Mail
Mobiltelefonnummer zum Erhalt des Bestätigungscodes
Solange Sie die E-Mail erhalten können/ Der Bestätigungscode bedeutet, dass Sie standardmäßig der Eigentümer des Kontos sind
Was ist Autorisierung?
Der Benutzer gewährt Berechtigung für Anwendungen von Drittanbietern, auf bestimmte Ressourcen des Benutzers zuzugreifen
Wenn Sie eine mobile Anwendung oder APP installieren, werden Sie gefragt, ob Sie Berechtigungen erteilen dürfen (Zugriff auf Fotoalben, geografischer Standort usw.). Greifen Sie auf das WeChat-Applet zu. Wenn Sie sich anmelden, fragt das Applet, ob Sie Berechtigungen erteilen dürfen (persönliche Informationen wie Spitzname, Avatar, Region, Geschlecht usw. erhalten).
Die Möglichkeiten zur Autorisierung sind: Cookie , Sitzung, Token, OAuth In dieser Zeit führte Shang Yang seine Reform durch und erfand den Fotoposten. Der Fotoaufkleber wird von der Regierung herausgegeben und besteht aus einer glatten und fein polierten Bambustafel, auf der das Profilbild und der Geburtsort des Inhabers eingraviert sind. Chinesen müssen es haben, wenn sie es nicht haben, gelten sie als verdeckte Ermittler oder Spione.
Im wirklichen Leben wird jeder einen exklusiven Einwohnerausweis haben, ein rechtsgültiges Dokument, das zum Nachweis der Identität des Inhabers dient. Über den Personalausweis können wir Mobiltelefonkarten/Bankkarten/Privatkredite/Transport usw. beantragen. Dies ist das
zertifizierte Zertifikat.
In Internetanwendungen verfügen allgemeine Websites (z. B. Nuggets) über zwei Modi: Gastmodus und Anmeldemodus. Im Gastmodus können Sie die Artikel auf der Website wie gewohnt durchsuchen. Wenn Sie Artikel liken/sammeln/teilen möchten, müssen Sie sich anmelden oder ein Konto registrieren. Wenn sich der Benutzer erfolgreich anmeldet, stellt der Server ein Token an den vom Benutzer verwendeten Browser aus. Jedes Mal, wenn der Browser eine Anfrage sendet, bringt er dieses Token mit, das Sie verwenden können Funktionen, die im Gastmodus nicht verfügbar sind.
Was sind Cookies?
HTTP ist ein zustandsloses Protokoll (kein Speicher für die Transaktionsverarbeitung, jedes Mal, wenn die Client- und Serversitzung abgeschlossen ist, speichert der Server keine Sitzungsinformationen
): Jede Anfrage ist vollständig Unabhängig davon kann der Server die Identitätsinformationen des aktuellen Besuchers nicht bestätigen und nicht feststellen, ob der Absender der letzten Anfrage und der Absender dieser Zeit dieselbe Person sind. Um Sitzungen zu verfolgen (um zu wissen, wer mich besucht), müssen der Server und der Browser daher aktiv einen Status beibehalten. Dieser Status wird verwendet, um den Server darüber zu informieren, ob die beiden Anforderungen davor und danach vom selben Browser stammen. Dieser Zustand muss durch Cookies oder Sitzungen erreicht werden.
Cookies werden auf der Clientseite gespeichert:
Ein Cookie ist ein kleines Datenelement, das vom Server an den Browser des Benutzers gesendet und lokal gespeichert wird. Es wird übertragen und an den Server gesendet, wenn der Browser das nächste Mal eine Anfrage stellt derselbe Server.
Cookies sind nicht domänenübergreifend:
Jedes Cookie ist an einen einzelnen Domänennamen gebunden und kann nicht unter anderen Domänennamen verwendet werden.
Die gemeinsame Nutzung zwischen Domänennamen der ersten Ebene und Domänennamen der zweiten Ebene ist zulässig ist Domain)
Was ist Sitzung? Auf der Serverseite wird die Sitzungs-ID im Cookie des Clients gespeichert.
Sitzungsauthentifizierungsprozess:
Wenn der Benutzer den Server zum ersten Mal anfordert, erstellt der Server die entsprechende Sitzung basierend auf den vom Benutzer übermittelten relevanten Informationen Die eindeutigen Identifikationsinformationen dieser Sitzung, SessionID, werden an den Browser zurückgegeben, wenn die Anfrage zurückgegeben wird
Nachdem der Browser die vom Server zurückgegebenen SessionID-Informationen erhält, speichert er diese Informationen in einem Cookie. Gleichzeitig zeichnet das Cookie auf, zu welchem Domainnamen diese SessionID gehört Wenn der Benutzer den Server zum zweiten Mal besucht. Die Anfrage ermittelt automatisch, ob unter diesem Domänennamen Cookie-Informationen vorhanden sind. Wenn dies der Fall ist, werden die Cookie-Informationen automatisch an den Server gesendet. Der Server erhält die Sitzungs-ID vom Cookie und findet dann die entsprechende Sitzung basierend auf der Sitzungs-ID Wenn die Informationen nicht gefunden werden, bedeutet dies, dass der Benutzer nicht angemeldet ist oder die Anmeldung ungültig ist. Wenn die Sitzung gefunden wird, beweist dies, dass der Benutzer angemeldet ist und die folgenden Vorgänge ausführen kann.
Gemäß dem oben genannten Prozess ist
SessionID eine Brücke zwischen Cookie und Sitzung
. Die meisten Systeme verwenden dieses Prinzip auch, um den Anmeldestatus des Benutzers zu überprüfen.
Empfehlungen zu verwandten Themen:
php-Sitzung (Thema)
Der Unterschied zwischen Cookie und Session
Sicherheit: Session ist sicherer als Cookie. Session wird auf der Serverseite und Cookie auf der Clientseite gespeichert.
Verschiedene Arten von Zugriffswerten: Cookie unterstützt nur das Speichern von Zeichenfolgendaten. Wenn Sie andere Datentypen festlegen möchten, müssen Sie diese in eine Zeichenfolge konvertieren.
Verschiedene Gültigkeitsdauern: Cookies können so eingestellt werden, dass sie für einen langen Zeitraum gespeichert werden, wie z. B. die von uns häufig verwendete Standard-Anmeldefunktion. Sitzungen haben im Allgemeinen eine kurze Ablaufzeit und verfallen, wenn der Client geschlossen wird (standardmäßig). oder die Sitzung läuft ab.
Unterschiedliche Speichergrößen: Die von einem einzelnen Cookie gespeicherten Daten können 4 KB nicht überschreiten. Eine Sitzung kann viel mehr Daten speichern als Cookies, aber wenn es zu viele Besuche gibt, werden zu viele Serverressourcen belegt.
Was ist ein Token? Zugriffstoken die aktuelle Uhrzeit), Vorzeichen (Signatur, die ersten Ziffern des Tokens werden mithilfe eines Hash-Algorithmus zu einer hexadezimalen Zeichenfolge einer bestimmten Länge komprimiert)
Eigenschaften:
Der Server ist zustandslos und kann gut skaliert werden
Unterstützt mobile Geräte verifizieren Benutzername und Passwort
Nach erfolgreicher Überprüfung stellt der Server ein Token aus und sendet das Token an den ClientNachdem der Client das Token erhalten hat, speichert er es, z. B. In Cookies oder im lokalen Speicher
Jedes Mal, wenn der Client eine Anfrage stellt Ressourcen vom Server müssen das vom Server ausgegebene Token mitbringenDer Server empfängt die Anfrage und überprüft dann das in der Client-Anfrage enthaltene Token. Wenn die Überprüfung erfolgreich ist, werden die angeforderten Daten an den Client zurückgegeben
Jede Anfrage muss ein Token enthalten und das Token muss im HTTP-Header platziert werden
Die tokenbasierte Benutzerauthentifizierung ist eine serverseitige zustandslose Authentifizierungsmethode. Der Server muss keine Tokendaten speichern. Die Rechenzeit für das Parsen des Tokens wird durch den Speicherplatz der Sitzung ersetzt, wodurch der Druck auf den Server verringert und häufige Datenbankabfragen reduziert werden. Das Token wird vollständig von der Anwendung verwaltet, sodass die gleiche Ursprungsaktualisierungsrichtlinie vermieden werden kann
Eine andere Art von Token – Aktualisierungstoken
Aktualisierungstoken ist ein Token, der speziell zum Aktualisieren von Zugriffstokens verwendet wird. Wenn kein Aktualisierungstoken vorhanden ist, können Sie auch das Zugriffstoken aktualisieren. Bei jeder Aktualisierung muss der Benutzer jedoch seinen Anmeldebenutzernamen und sein Kennwort eingeben, was sehr mühsam ist. Mit dem Aktualisierungstoken kann dieses Problem reduziert werden. Der Client verwendet das Aktualisierungstoken direkt, um das Zugriffstoken zu aktualisieren, ohne dass der Benutzer zusätzliche Vorgänge ausführen muss.
Der Zugriffstoken hat eine relativ kurze Gültigkeitsdauer. Wenn der Zugriffstoken aufgrund des Ablaufs ungültig wird, kann der Benutzer mithilfe des Aktualisierungstokens einen neuen Token erhalten Melde dich einfach erneut an.
Aktualisierungstoken und Ablaufzeit werden in der Datenbank des Servers gespeichert und nur bei der Beantragung eines neuen Zugriffstokens überprüft. Es hat keinen Einfluss auf die Antwortzeit der Geschäftsschnittstelle und muss nicht wie die Sitzung im Speicher gehalten werden. Viele Anfragen.
Der Unterschied zwischen Token und Sitzung
Sitzung ist ein Mechanismus, der den Sitzungsstatus des Servers und des Clients aufzeichnet, wodurch der Server zustandsbehaftet wird und Sitzungsinformationen aufzeichnen kann. Und Token ist das Token, die Ressourcenanmeldeinformationen, die für den Zugriff auf die Ressourcenschnittstelle (API) erforderlich sind. Token macht den Server zustandslos und speichert keine Sitzungsinformationen.
Session und Token widersprechen sich nicht. Als Identitätsauthentifizierungstoken ist die Sicherheit besser als bei Session, da jede Anfrage signiert ist und Überwachungs- und Wiederholungsangriffe verhindern kann, während Session auf die Verbindungsschicht angewiesen ist, um die Kommunikationssicherheit zu gewährleisten.
Wenn Sie eine zustandsbehaftete Sitzung implementieren müssen, können Sie dennoch eine Sitzung hinzufügen, um einen Zustand auf der Serverseite zu speichern.
Die sogenannte Session-Authentifizierung speichert lediglich Benutzerinformationen in Session. Aufgrund der Unvorhersehbarkeit der SessionID gilt sie vorerst als sicher. Und Token, wenn es sich auf OAuth-Token oder einen ähnlichen Mechanismus bezieht, stellt Authentifizierung und Autorisierung bereit. Die Authentifizierung erfolgt für Benutzer und die Autorisierung erfolgt für die App. Der Zweck besteht darin, einer App das Recht zu geben, auf die Informationen eines Benutzers zuzugreifen. Der Token hier ist einzigartig. Eine Übertragung auf andere Apps oder andere Nutzer ist nicht möglich. Die Sitzung bietet nur eine einfache Authentifizierung. Das heißt, solange diese Sitzungs-ID vorhanden ist, wird davon ausgegangen, dass dieser Benutzer über alle Rechte verfügt. Diese Daten müssen streng vertraulich behandelt werden und dürfen nur auf der Website gespeichert und nicht an andere Websites oder Apps von Drittanbietern weitergegeben werden. Um es einfach auszudrücken:
Wenn Ihre Benutzerdaten möglicherweise an Dritte weitergegeben werden müssen oder einem Dritten gestatten müssen, die API-Schnittstelle aufzurufen, verwenden Sie Token. Wenn es immer nur um die eigene Website und die eigene App geht, spielt es keine Rolle, was man nutzt.
Was ist JWT
JSON Web Token (kurz JWT) ist derzeit die beliebteste
domänenübergreifende Authentifizierungslösung.
ist ein
Authentifizierungs- und Autorisierungsmechanismus.
JWT ist ein JSON-basierter offener Standard (RFC 7519), der für die
Übergabe von Ansprüchen zwischen Webanwendungsumgebungen implementiert ist. JWT-Ansprüche werden im Allgemeinen verwendet, um authentifizierte Benutzeridentitätsinformationen zwischen Identitätsanbietern und Dienstanbietern weiterzugeben, um Ressourcen von Ressourcenservern zu erhalten. Wird beispielsweise für die Benutzeranmeldung verwendet.
Sie können den HMAC-Algorithmus oder den öffentlichen/privaten RSA-Schlüssel verwenden, um JWT zu signieren. Aufgrund der Existenz digitaler Signaturen sind die übermittelten Informationen glaubwürdig.
Lehrer Yuan Yifengs Einführungs-Tutorial zu JSON Web Token ist sehr leicht zu verstehen, daher werde ich hier nicht auf die Details eingehen
Generate JWTjwt.io/
www.jsonwebtoken.io/
Das Prinzip von JWT
JWT-Authentifizierungsprozess:
Der Benutzer gibt den Benutzernamen/das Passwort ein, um sich anzumelden. Nach erfolgreicher Authentifizierung des Servers wird ein JWT an den Client zurückgegeben.
Der Client speichert das Token lokal (normalerweise Localstorage verwenden, Sie können auch Cookies verwenden)
Wenn der Benutzer auf eine geschützte Route oder Ressource zugreifen möchte, muss er den Bearer-Modus verwenden, um JWT im Autorisierungsfeld des Anforderungsheaders hinzuzufügen Folgendes
Authorization: Bearer <token>复制代码</token>
Nach dem Login kopieren
Die serverseitige Schutzroute überprüft die JWT-Informationen im Anforderungsheader Autorisierung Wenn es legal ist, ist das Verhalten des Benutzers zulässig
Da JWT in sich geschlossen ist (es enthält einige Sitzungsinformationen). ), reduziert es die Notwendigkeit, die Datenbank abzufragen
Da JWT keine Cookies verwendet, können Sie jeden Domänennamen verwenden, um Ihre API-Dienste bereitzustellen, ohne sich Gedanken über die domänenübergreifende Ressourcenfreigabe (CORS) machen zu müssen
Denn der Status des Benutzers ist nicht mehr Es wird im Speicher des Servers gespeichert, daher handelt es sich um einen zustandslosen Authentifizierungsmechanismus.
Wenn der Benutzer auf eine geschützte Route oder Ressource zugreifen möchte, kann er diese in ein Cookie einfügen und automatisch senden. Dies ist jedoch nicht domänenübergreifend möglich. Ein besserer Ansatz besteht daher darin, sie in das Autorisierungsfeld der HTTP-Anfrage einzufügen Header. Fügen Sie JWT mithilfe des Bearer-Musters hinzu.
GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>复制代码</token>
Nach dem Login kopieren
Der Status des Benutzers wird nicht im Speicher des Servers gespeichert. Dies ist ein
zustandsloser Authentifizierungsmechanismus
Das geschützte Routing des Servers überprüft die JWT-Informationen im Autorisierungsheader der Anfrage und wenn sie legal sind Dem Benutzer wird das Verhalten gestattet.
Da JWT in sich geschlossen ist, ist es weniger erforderlich, die Datenbank abzufragen. Diese Funktionen von JWT ermöglichen es uns, Daten-API-Dienste bereitzustellen oder sogar einen Download-Streaming-Dienst zu erstellen, der sich vollständig auf seine zustandslose Natur verlässt.
Da JWT keine Cookies verwendet, können Sie jeden Domänennamen verwenden, um Ihre API-Dienste bereitzustellen, ohne
sich Gedanken über die domänenübergreifende gemeinsame Nutzung von Ressourcen machen zu müssen
(CORS)
Methode 2
Wenn es um domänenübergreifende Nutzung geht , können Sie das JWT in den Datenkörper der POST-Anfrage einfügen.
Methode 3
Übertragung per URL
http://www.example.com/user?token=xxx复制代码
Nach dem Login kopieren
JWT im Projekt verwenden
Der Unterschied zwischen Projektadresse
Token und JWT
Das Gleiche:
Token
Beide können Benutzerinformationen aufzeichnen
Beide machen den Server zustandslos
Erst nach erfolgreicher Überprüfung kann der Client auf die geschützten Ressourcen auf dem Server zugreifen
Unterschied:
Token: Wenn der Server das vom Client gesendete Token überprüft, muss er auch die Datenbank abfragen, um Benutzerinformationen zu erhalten, und dann überprüfen, ob das Token gültig ist.
JWT: Das Token und die Nutzlast werden verschlüsselt und auf dem Client gespeichert. Der Server muss den Schlüssel nur zum Entschlüsseln zur Überprüfung verwenden (die Überprüfung wird auch von JWT selbst durchgeführt. Es ist nicht erforderlich, die Abfragedatenbank abzufragen oder zu reduzieren , weil JWT eigenständige Benutzerinformationen und verschlüsselte Daten sind.
Gemeinsame Front-End- und Back-End-Authentifizierungsmethoden
Session-Cookie
Token-Überprüfung (einschließlich JWT, SSO)
OAuth2.0 (offene Autorisierung)
Gemeinsame Verschlüsselungsalgorithmen
Hash-Algorithmus, auch bekannt als Hash-Algorithmus, Hash-Funktion Ein Hash Funktion ist eine Methode, aus beliebigen Daten einen kleinen digitalen „Fingerabdruck“ zu erstellen. Hash-Algorithmen mischen die Daten neu, um einen neuen Hash-Wert zu erstellen.
Der Hash-Algorithmus wird hauptsächlich verwendet, um die Authentizität (dh Integrität) der Daten sicherzustellen. Das heißt, der Absender sendet die Originalnachricht und den Hash-Wert zusammen, und der Empfänger verwendet dieselbe Hash-Funktion, um zu überprüfen, ob die Originaldaten authentisch sind.
Hash-Algorithmen haben normalerweise die folgenden Eigenschaften:
Genauso schnell: Die Originaldaten können den Hash-Wert schnell berechnen.
Inverse Schwierigkeit: Es ist grundsätzlich unmöglich, die Originaldaten aus dem Hash-Wert abzuleiten.
Eingabesensitiv: das Original Daten Solange es eine geringfügige Änderung gibt, wird der erhaltene Hash-Wert sehr unterschiedlich sein. Konfliktvermeidung: Es ist schwierig, unterschiedliche Originaldaten zu finden, um den gleichen Hash-Wert zu erhalten. Die Anzahl der Atome im Universum liegt ungefähr zwischen 10 und Die 60. Potenz und die 80. Potenz haben also genug Platz, um alle Möglichkeiten abzudecken. Wenn der Algorithmus gut ist, ist die Wahrscheinlichkeit einer Kollision sehr gering:
2 hoch 128. Potenz ist 340282366920938463463374607431768211456 39. Potenzstufe
2 von 160 Die Potenz beträgt 1,4615016373309029182036848327163e+48, also 10 erhöht auf die 48. Potenz von
2 ist 1,157920892373161954235709 8500869 × 10 hoch 77, also 10 hoch 77
Das Obige kann nicht garantiert werden. Wenn die Daten böswillig manipuliert werden, können sowohl die Originaldaten als auch der Hash-Wert böswillig manipuliert werden. Um sicherzustellen, dass sie nicht manipuliert werden, können Sie RSA verwenden öffentliches und privates Schlüsselschema, kombiniert mit dem Hashwert.
Der Hash-Algorithmus wird hauptsächlich verwendet, um Fehler bei der Computerübertragung zu verhindern. Frühe Computer verwendeten die ersten 7 Bits der Daten und den 8. Bit-Paritätsprüfcode, um sie zu schützen (12,5 % Verschwendungseffizienz sind gering). oder Datei, durch Hashing Der Algorithmus generiert einen 128-Bit- oder 256-Bit-Hash-Wert. Wenn bei der Überprüfung ein Problem auftritt, ist eine erneute Übertragung erforderlich.
FAQ
Zu berücksichtigende Punkte bei der Verwendung von Cookies
Da sie auf der Clientseite gespeichert werden, können sie vom Client leicht manipuliert werden. Vor der Verwendung muss die Rechtmäßigkeit überprüft werden.
Speichern Sie keine sensiblen Daten, z B. Benutzerkennwörter und Kontostände.
Die Verwendung von httpOnly verbessert die Sicherheit bis zu einem gewissen Grad.
Versuchen Sie, die Größe der speicherbaren Cookies zu reduzieren.
Stellen Sie die richtige Domäne und den richtigen Pfad ein Übertragung.
Cookies können nicht domänenübergreifend sein.
Eine Website kann bis zu 20 Cookies speichern, und Browser unterstützen Cookies im Allgemeinen nicht sehr gut, und Sitzungen müssen auf Basis von Cookies implementiert werden Daher werden Token häufig auf mobilen Endgeräten verwendet. Wenn viele Benutzer gleichzeitig online sind, belegen diese Sitzungen mehr Speicher müssen regelmäßig auf der Serverseite bereinigt werden
Wenn die Website übernommen wird
Bei der Bereitstellung eines Clusters
werden Sie auf das Problem stoßen, wie Sitzungen zwischen mehreren Webservern gemeinsam genutzt werden können. Da die Sitzung von einem einzelnen Server erstellt wird, der Server, der Benutzeranfragen verarbeitet, jedoch nicht unbedingt der Server ist, der die Sitzung erstellt hat, kann der Server keine Informationen wie Anmeldeinformationen abrufen, die zuvor in die Sitzung eingegeben wurden. Wenn mehrere Anwendungen Sitzungen gemeinsam nutzen möchten, treten zusätzlich zu den oben genannten Problemen auch domänenübergreifende Probleme auf, da möglicherweise unterschiedliche Anwendungen auf unterschiedlichen Hosts bereitgestellt werden und in jeder Anwendung eine domänenübergreifende Cookie-Verarbeitung durchgeführt werden muss.
sessionId wird in Cookies gespeichert. Was passiert, wenn der Browser Cookies verbietet oder keine Cookies unterstützt?
Im Allgemeinen folgt auf die Sitzungs-ID der URL-Parameter, um die URL neu zu schreiben, sodass die Sitzung nicht unbedingt durch Cookies implementiert werden muss
Das mobile Endgerät unterstützt Cookies nicht sehr gut und die Sitzung muss basierend auf der Sitzung implementiert werden auf Cookies, daher wird das mobile Endgerät häufig als Token verwendet in Erinnerung. Redis eignet sich beispielsweise sehr gut für Ihre Token-Abfrageanforderungen.
Token wird vollständig von der Anwendung verwaltet, sodass die Same-Origin-Richtlinie vermieden werden kann
Token kann CSRF-Angriffe vermeiden (da Cookies nicht mehr benötigt werden)
Das mobile Endgerät unterstützt Cookies nicht sehr gut , und die Sitzung erfordert Token, die auf Cookies basieren und häufig auf mobilen Endgeräten verwendet werden.
Bei der Verwendung von JWT zu berücksichtigende Punkte über Cross-Domain Resource Sharing Issues (CORS)
JWT ist standardmäßig nicht verschlüsselt, kann aber auch verschlüsselt werden. Nach der Generierung des ursprünglichen Tokens kann dieser erneut mit dem Schlüssel verschlüsselt werden.
JWT Geheime Daten können nicht ohne Verschlüsselung in JWT geschrieben werden.
JWT kann nicht nur zur Authentifizierung, sondern auch zum Informationsaustausch genutzt werden. Durch den effektiven Einsatz von JWT kann die Anzahl der Abfragen der Datenbank durch den Server reduziert werden.
Der größte Vorteil von JWT besteht darin, dass der Server keine Sitzung mehr speichern muss, sodass das Serverauthentifizierungs- und Authentifizierungsgeschäft problemlos erweitert werden kann. Dies ist jedoch auch der größte Nachteil von JWT: Da der Server den Sitzungsstatus nicht speichern muss, kann er während der Verwendung kein Token verwerfen oder die Berechtigungen des Tokens ändern. Das heißt, sobald das JWT ausgegeben wurde, bleibt es immer gültig, bis es abläuft, es sei denn, der Server stellt zusätzliche Logik bereit.
Das JWT selbst enthält Authentifizierungsinformationen, und sobald diese durchgesickert sind, kann jeder alle Berechtigungen des Tokens erhalten. Um Diebstahl zu reduzieren, sollte die Gültigkeitsdauer von JWT relativ kurz eingestellt werden. Für einige wichtigere Berechtigungen sollten Benutzer bei der Verwendung erneut authentifiziert werden.
JWT eignet sich für die einmalige Befehlsauthentifizierung. Auch wenn das Risiko besteht, ist es sehr gering, dass für jeden Vorgang ein neues JWT generiert wird um das JWT zu retten und wirklich Staatenlosigkeit zu erreichen.
Um Diebstahl zu reduzieren, sollte JWT nicht im Klartext über das HTTP-Protokoll, sondern über das HTTPS-Protokoll übertragen werden.
Dinge, die bei der Verwendung von Verschlüsselungsalgorithmen zu beachten sind
Speichern Sie
Passwörter niemals in
Klartext
Verwenden Sie immer Hashing-Algorithmen, um Passwörter zu verarbeiten, verwenden Sie niemals Base64 oder andere Codierungsmethoden, um Passwörter zu speichern, dies ist dasselbe wie das Speichern von Passwörtern im Klartext Das Speichern von Passwörtern ist dasselbe, verwenden Sie Hashing statt Codierung
. Kodierung und Verschlüsselung sind bidirektionale Prozesse, während Passwörter vertraulich sind und nur ihren Besitzern bekannt sein sollten. Dieser Prozess muss einseitig sein. Dazu wird Hashing verwendet. Es gibt nie eine Dekodierung eines Hashes, aber es gibt eine Dekodierung, wenn es eine Kodierung gibt, und eine Entschlüsselung, wenn es eine Verschlüsselung gibt.
Verwenden Sie niemals schwache oder fehlerhafte Hashing-Algorithmen wie MD5 oder SHA1, sondern nur starke Passwort-Hashing-Algorithmen.
Passwörter niemals im Klartext anzeigen oder senden, auch nicht an den Besitzer des Passworts. Wenn Sie die Funktion „Passwort vergessen“ benötigen, können Sie zufällig ein neues
Einmalpasswort
(das ist wichtig) generieren und dieses Passwort an den Benutzer senden.
Session-Sharing-Lösung unter verteilter Architektur
1. Sitzungsreplikation
Wenn sich die Sitzung auf einem Server ändert (Hinzufügen, Löschen, Ändern), serialisiert der Knoten den gesamten Inhalt der Sitzung und sendet ihn dann an alle anderen Knoten, unabhängig davon, ob andere Server Sitzungen benötigen oder nicht, um die Sitzungssynchronisation sicherzustellen
Vorteile:
Fehlertolerant, Sitzungen zwischen Servern können in Echtzeit reagieren.
Nachteile: Es wird einen gewissen Druck auf die Netzwerklast ausüben. Wenn das Sitzungsvolumen groß ist, kann es zu einer Netzwerküberlastung kommen und die Serverleistung verlangsamen. 2. Sticky-Session-/IP-Bindungsstrategie
Übernimmt den ip_hash-Mechanismus in Ngnix, um alle Anfragen für eine bestimmte IP an denselben Server zu leiten, d. h. den Benutzer an den Server zu binden.
Wenn der Benutzer zum ersten Mal eine Anfrage stellt, leitet der Load Balancer die Anfrage des Benutzers an Server A weiter. Wenn der Load Balancer eine Sticky Session einrichtet, wird jede nachfolgende Anfrage des Benutzers an Server A weitergeleitet, was einer Aufteilung der Sitzung entspricht Benutzer und Server A. Server A hängt zusammen. Dies ist der Sticky-Session-Mechanismus.
Vorteile:
Einfach, keine Bearbeitung der Sitzung erforderlich.
Nachteile: Fehlende Fehlertoleranz Wenn der aktuell aufgerufene Server ausfällt und der Benutzer auf den zweiten Server übertragen wird, sind seine Sitzungsinformationen ungültig. Anwendbare Szenarien: Ein Ausfall hat nur geringe Auswirkungen auf Kunden; ein Serverausfall ist ein Ereignis mit geringer Wahrscheinlichkeit
. Implementierungsmethode: Am Beispiel von Nginx kann durch Konfigurieren des ip_hash-Attributs im Upstream-Modul eine dauerhafte Sitzung erreicht werden.
3. Sitzungsfreigabe (häufig verwendet)
Verwenden Sie verteilte Caching-Lösungen wie Memcached und Redis, um die Sitzung zwischenzuspeichern, aber Memcached oder Redis müssen ein Cluster sein.
Speichern Sie die Sitzung in Redis, obwohl die Architektur kompliziert wird , und Sie müssen noch einmal auf Redis zugreifen, aber die Vorteile dieser Lösung sind auch großartig:
ermöglicht die gemeinsame Nutzung von Sitzungen
kann horizontal erweitert werden (Hinzufügen von Redis-Servern);
die Sitzung geht nicht verloren, wenn der Server neu gestartet wird (aber bitte achten Sie auch auf den Sitzungsaktualisierungs-/Ungültigkeitsmechanismus in Redis). 4. Sitzungspersistenz Die Website hat eine große Anzahl von Besuchen, das Speichern der Sitzung in der Datenbank verursacht großen Schaden für den Datenbankdruck und es ist zusätzlicher Aufwand für die Pflege der Datenbank erforderlich.
Wird die Sitzung wirklich verschwinden, solange Sie den Browser schließen?
Das ist nicht richtig. Bei Sitzungen behält der Server die Sitzung bei, es sei denn, das Programm benachrichtigt den Server. Das Programm sendet normalerweise eine Anweisung zum Löschen der Sitzung, wenn sich der Benutzer abmeldet. Der Browser benachrichtigt den Server jedoch vor dem Schließen nie aktiv darüber, dass er geschlossen wird, sodass der Server keine Chance hat, zu erfahren, dass der Browser geschlossen wurde. Der Grund für diese Illusion ist, dass die meisten Sitzungsmechanismen Sitzungscookies zum Speichern verwenden Sitzungs-ID, und die Sitzungs-ID verschwindet nach dem Schließen des Browsers und die ursprüngliche Sitzung kann nicht gefunden werden, wenn eine erneute Verbindung zum Server hergestellt wird. Wenn das vom Server gesetzte Cookie auf der Festplatte gespeichert wird oder eine Methode verwendet wird, um den vom Browser gesendeten HTTP-Anforderungsheader neu zu schreiben und die ursprüngliche Sitzungs-ID an den Server zu senden, kann die ursprüngliche Sitzung weiterhin geöffnet werden, wenn der Browser geöffnet ist wieder geöffnet. GenauDa das Schließen des Browsers nicht zum Löschen der Sitzung führt, wird der Server gezwungen, eine Ablaufzeit für die Sitzung festzulegen. Wenn die Zeit seit der letzten Verwendung der Sitzung durch den Client überschritten wird, geht der Server davon aus, dass die Wenn der Client seine Aktivitäten gestoppt hat, wird die Sitzung gelöscht, um Speicherplatz zu sparen.
Projektadresse
Verwendung von JWT im Projekt
Postscript In diesem Artikel geht es nur um theoretisches Wissen basierend auf meinem eigenen Verständnis, da ich mit Backend-/Algorithmuskenntnissen nicht sehr vertraut bin, falls vorhanden Wenn es Irrtümer gibt, informieren Sie mich bitte, vielen Dank
Wenn dieser Artikel für Sie hilfreich ist, geben Sie ihm bitte ein „Gefällt mir“~~
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Genau
