Eine kurze Erläuterung, wo das vom Knoten mithilfe von JWT generierte Token gespeichert werden soll

A: Normalerweise im Client gespeichert.

jwt oder JSON Web Token ist ein Authentifizierungsprotokoll, das im Allgemeinen zum Überprüfen der Identitätsinformationen und Identitätsberechtigungen einer Anfrage verwendet wird.

Als ich heute Morgen auf einer bestimmten Website surfte, traf ich einen Klassenkameraden, der diese Frage stellte. Er war sehr neugierig auf den Speicherort von JWT. Ich habe mich vor einiger Zeit zufällig mit diesem Thema beschäftigt und scheue mich daher nicht, diese Frage unaufgefordert zu beantworten.
Zuerst war ich auch neugierig, wie ich dieses Token speichern sollte, und wollte fast Redis zum Speichern dieses Tokens verwenden.

Später fand ich durch einige Recherchen heraus, dass der Server dieses Token nicht speichern muss. Der Kunde muss es lediglich speichern, unabhängig davon, welche Methode verwendet wird. Sie können den Benutzer sogar bitten, eine Notiz zu schreiben und sie in die Tasche zu stecken!

Wie funktioniert dieses Token?

Lassen Sie uns zunächst über Vorgänge sprechen, die serverseitigen Speicher erfordern, also den herkömmlichen Sitzungsansatz.

Um den Benutzer anzumelden, müssen Sie zunächst eine Anmeldetabelle auf dem Server pflegen. Diese Anmeldetabelle kann im Cache oder in der Datenbank abgelegt werden.
Wenn sich der Benutzer anmeldet, werden die Benutzerinformationen in die Anmeldetabelle geschrieben und anschließend eine Anmelde-ID, auch Sitzung genannt, abgeleitet. Diese Sitzung wird an den Client zurückgegeben, damit der Client diese Informationen bei der nächsten Anforderung abrufen kann.

Für die Frontend-Leute ist dieser Vorgang normalerweise unbemerkt. Die Backend-Leute verwenden ein HTTP-Headerfeld namens Set-Cookie, um die Daten selbst in das Browser-Cookie zu schreiben. Wenn dann eine Anfrage gestellt wird, schreibt der Browser das Cookie selbst in den Anfrageheader.

Wenn der Client den Zugriff auf den Server anfordert, ruft der Server die Sitzung im Cookie ab, durchsucht dann die Anmeldetabelle nach Benutzerinformationen, überprüft die Benutzerberechtigungen und führt dann die normale Geschäftsinteraktion durch.

Nun möchte ich aus verschiedenen Gründen keine Login-Tabelle pflegen. Was soll ich tun?
Es ist ganz einfach. Senden Sie einfach die Benutzerinformationen an den Client und lassen Sie den Client die Benutzerinformationen jedes Mal übermitteln. Auf diese Weise müssen Sie bei einer eingehenden Anfrage nicht einmal die Tabelle überprüfen, sondern können direkt erkennen, welcher Benutzer die Anfrage stellt.

Auf diese Weise werden jedoch die Informationen des Benutzers offengelegt. Die Mittelsmänner mögen diese Art von unkomplizierten Anfragen am meisten. Sie nehmen einfach einen Stuhl und sitzen ein paar Tage lang auf Ihrem Server-Port, und alle Verwandten in Ihrer Datenbank werden anderen klar zugänglich gemacht.

Das wird definitiv nicht funktionieren. Was sollen wir also tun?

Fügen Sie einfach ein Passwort hinzu und verwirren Sie es. Auf diese Weise werden die Leute, wenn sie Ihr Token erhalten, eine Weile verwirrt sein und höchstwahrscheinlich achtlos weggehen, sodass nur eine kleine Anzahl gut vorbereiteter Leute (KPI) übrig bleibt, die sich mit dem Knacken des Tokens herumschlagen müssen.

Sobald Sie es auf dem Server entschlüsseln, erhalten Sie die Benutzerinformationen. Ebenso schreiben Sie die Ablaufzeit in den Geheimtext. Wenn diese abläuft, wird mit einem 401-Fehler auf die Anmeldeseite gesprungen. Auf diese Weise wird eine Lösung entwickelt, die keine Back-End-Speicherung von Anmeldeinformationen erfordert.

Dies ist das grundlegendste Funktionsprinzip von jwt: Die Identitätsinformationen werden dem Client zur sicheren Aufbewahrung übergeben.

Das von jwt generierte Token besteht aus drei Teilen: Header, Payload und Signatur, die durch einen Dezimalpunkt „.“ getrennt sind.

Der Header, also die Kopfzeileninformationen, beschreibt die grundlegenden Informationen des Tokens und liegt im JSON-Format vor:

{
    "alg":"HS256",
    "typ":"JWT"
}

„alg“ stellt den Verschlüsselungsalgorithmus dar, der zum Generieren des Signaturteils verwendet wurde, und „typ“ gibt an, dass das Token vom Typ „jwt“ ist.

Die Nutzlast sind Ihre Benutzerdaten, ebenfalls im JSON-Format. JWT empfiehlt jedoch nicht, vertrauliche Daten darin abzulegen, da die Nutzlast in der Spezifikation mit dem Header identisch ist und nur einmal Base64-codiert und auf dem Token angezeigt wird.

Die Signatur ist die Signatur dieses Tokens. Normalerweise handelt es sich dabei um eine Zeichenfolge, die durch die Verschlüsselung des vorherigen Headers und der Nutzlast zusammen mit einer privaten Schlüsselzeichenfolge generiert wird, die Sie selbst definieren.

Wie bereits erwähnt, kodiert jwt den Inhalt der Nutzlast nur mit base64, sodass es für Angreifer sehr einfach ist, Ihren Inhalt zu ändern. Sie kennen jedoch Ihren privaten Schlüssel nicht und können daher nach der Änderung nicht die richtige Signatur generieren. Sie verwenden Verschlüsselung, um den Header.Payload der Anforderung erneut zu überprüfen, und stellen fest, dass er nicht mit der Signatur übereinstimmt. Zu diesem Zeitpunkt können Sie eindeutig erkennen, dass jemand Probleme verursacht, und direkt eine 500 zurückgeben, um vorzutäuschen, dass der Server ausgefallen ist.
Wenn Sie mehr Sicherheit wünschen, wird empfohlen, während des gesamten Prozesses das https-Protokoll für die Anforderungskommunikation zu verwenden.

Nachdem Sie nun verstanden haben, wie das funktioniert, ist es natürlich nicht unmöglich, sich Ihre eigenen widerlichen Spezifikationen auszudenken, zum Beispiel die Nutzlast erneut zu verschlüsseln und sie dann mit gzip zu komprimieren usw.

Was sind also die Vorteile der Verwendung von jwt?

Der erste Punkt ist, dass der Server keine Login-Tabelle pflegen muss, was insbesondere bei vielen Benutzern Platz spart.
Der zweite Punkt ist, dass die Erweiterung einfach ist, vorausgesetzt, Sie verursachen keine Probleme und halten sich beim Ausdruck Ihrer Inhalte ehrlich an das JSON-Format.
Der dritte Punkt ist, dass es zustandslos ist. Solange der Server das Parsen unterstützt, kann er Geschäfte abwickeln. Es ist nicht erforderlich, einen speziellen Mechanismus zum Teilen von Sitzungen und Hinzufügen von Maschinen einzurichten.
Viertens unterstützt es eine Vielzahl von Clients und kann auch ohne Cookie-Unterstützung gespielt werden.
Der Nachteil besteht darin, dass diese Daten bei jeder Anfrage hin und her transportiert werden müssen, was den Anfrageinhalt deutlich erhöht. Darüber hinaus müssen Sie jede eingehende Anfrage überprüfen, den Header und die Nutzlast verschlüsseln und die Signatur überprüfen, was die Bearbeitungszeit der Anfrage ebenfalls verlängert. Im Vergleich zu herkömmlichen Operationen handelt es sich hierbei tatsächlich um einen Kompromiss zwischen Zeit und Platz. Letztendlich hängt es von Ihrer Wahl ab.

Dies ist das Ende dieses Artikels darüber, wo das von Node mithilfe von jwt generierte Token gespeichert werden soll. Weitere Informationen darüber, wo das von jwt generierte Token gespeichert werden soll, finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!