Knoten js, JWT-Token und Logik dahinter

Sie müssen die Antworten auf alle Ihre vorherigen Fragen bereits anhand der vorherigen Antworten der anderen Benutzer herausgefunden haben, aber ich werde versuchen, die Dinge auch für andere etwas aufzuhellen:

1 - Wo werden JWT-Tokens beim Aufruf von sign () gespeichert?

  

Wenn Sie signieren, wird das signierte Token nicht irgendwo gespeichert   zurückgegeben von der Zeichenfunktion, dann müssen Sie es an den Client senden   damit kann auf der Client-Seite gespeichert werden. (z.B. Sitzungsspeicher,   lokaler Speicher oder Cookie)

2 - Muss ich das Token jedes Mal verifizieren (), wenn eine geschützte URL aufgerufen wird? wenn ja warum?

  

Ja, das tust du. Die Idee ist, sobald der Kunde das Token hat, werden sie senden   das Token an den Server jedes Mal, wenn sie eine Anfrage stellen. Das Token ist   Wird vom Server verarbeitet, um festzustellen, ob ein bestimmter Client vorhanden ist   wurde bereits authentifiziert.

3 - Wenn ich ein neues Token für einen bereits signierten Benutzer einstelle, wird das alte Token (falls vorhanden) gelöscht? Was ist, wenn das Ablaufdatum nicht eingestellt ist oder beispielsweise 5 Jahre beträgt?

  

Etwas mit der Antwort zu Punkt 1 verbunden. Aufruf der Zeichenfunktion   wird nur ein weiteres Token generieren. Der Ablauf des Tokens ist   innerhalb des signierten Tokens selbst gespeichert. Also jedes Mal, wenn der Server ein Token bekommt   vom Client überprüft es das Ablaufdatum als Teil des Tokens   Überprüfung. Es ist wichtig zu beachten, dass das signierte Token nur das ist   "user_profile" -Objekt, das Sie als Parameter übergeben haben   Unterzeichnung, plus zusätzliche Felder wie das Ablaufdatum, die hinzugefügt werden   dieses Objekt.

     

So kann ein Client mehrere Token auf der Client-Seite gespeichert haben. Sie   sind alle gültig, solange sie noch nicht abgelaufen sind. Aber die   Idee ist, nur ein Token an den Client zu senden, wenn sie es waren   erneut authentifiziert, nachdem der alte abgelaufen ist.

4 - Warum kann ich keine neuen Tokens auf derselben Browser / App-Seite setzen? Ich erhalte einen ungültigen Signaturfehler, wenn ich ein neues Token registriere, aber das Token stimmt überein (ich habe es überprüft) Es ist, als ob ich nicht mehr als 1 Benutzer im selben Browser anmelden kann

  

Die Idee ist, einen Benutzer pro Browser zu haben. Da in diesem Fall der Browser   ist der Kunde. Ich kann mir keine Anwendungsfälle vorstellen, in denen Sie das tun müssten   Haben Sie mehrere Benutzer pro Browser / Client, so dass Sie es offensichtlich getan haben   etwas stimmt nicht. Das heißt nicht, dass es unmöglich ist, mehrere zu senden   Token zum selben Browser / Client.

1. Sie müssen das Token auf der Client-Seite speichern (lokaler Speicher oder Cookie)

2. Ja. HTTP ist zustandslos. Wenn Sie es nicht jedes Mal überprüfen, kann jemand Ihre URL ohne das Token oder mit einem ungültigen Token aufrufen. Wenn Sie sich Sorgen um die Leistung machen, ist eine HMACSHA256-Prüfung sehr schnell.

3. Das macht keinen Sinn, Sie müssen etwas falsch machen.

  

2 - Muss ich das Token immer verifizieren, wenn eine geschützte URL vorhanden ist?   namens? wenn ja warum?

Ja. Aber "verify" ist ein etwas verwirrender Begriff.

1. Wenn der Client anruft / authentifiziert, validiert der Server zuerst die Benutzeranmeldeinformationen für die Datenbank, um diesen Benutzer authentifizieren zu lassen. Und diese "teure" Operation wurde nur einmal für die gesamte Token-Lebensdauer durchgeführt. Dann bereitet der Server ein JSON-Objekt vor, das nützliche Benutzerinformationen enthält, und verschlüsselt es, um das JWT-Token zu erhalten.
2. Dieses Token wird nur einmal an den Client gesendet, in einem Browser gespeichert und dann bei jeder Clientanforderung an den Server an / api zurückgegeben.
3. Während der Verarbeitung der Client / API-Anforderung muss der Server das Token auf Gültigkeit verifizieren (JWT macht es für Sie). Dies bedeutet jedoch nicht, die Benutzeranmeldeinformationen erneut anhand der Datenbank zu überprüfen. Nur entschlüsseln Token, um JSON-Objekt zurück, HMAC-SHA256 Verifikation - ziemlich schnell.
4. Wenn ein JSON-Objekt mit nützlichen Benutzerinformationen (Ansprüchen) versehen ist, kann der Server diesem bestimmten Benutzer erlauben, auf die angeforderte Ressource unter / api-Route zuzugreifen.

Während der Token-Verifizierung ist keine Datenbankprüfung der Benutzeranmeldeinformationen erforderlich, da der Server dem empfangenen und verifizierten (erfolgreich entschlüsselten) Token vertrauen muss. Zur Identifizierung des Benutzers ist kein Speicher für Serversitzungen erforderlich.

Sie können sich JWT-Token wie eine einfache Sitzungsinformation vorstellen, die verschlüsselt auf dem Client gespeichert ist. Aber wenn Sie mehr Daten in einer Benutzersitzungs-Information zwischenspeichern müssen, brauchen Sie, denke ich, noch eine Art Sitzungsspeicher auf einem Server, was die JWT-Idee im Vergleich zur herkömmlichen Sitzungs-ID in Cookies fast nutzlos macht.

Entschuldigung. Dies sollte ein Kommentar zur vorherigen Antwort sein, aber ich habe nicht genug Rep zu kommentieren, damit er es geht

@sbaang: Ein weiterer Grund, jedes Mal zu überprüfen, ist, dass es im Token interessante "Claims2" geben könnte, die einem Benutzer den Zugriff auf bestimmte Endpoints erlauben, nicht alle. Also verifizieren Sie bei jeder Verifizierung nicht nur, ob Der Benutzer darf auf die geschützte API zugreifen, jedoch nicht auf einen gültigen Token, sondern auf einen Token, der dies ausdrücklich zulässt.