Das Aktualisieren eines Tokens wird durchgeführt, um mit dem Authentifizierungsdienst zu bestätigen, dass der Inhaber des Tokens noch über Zugriffsrechte verfügt. Dies ist erforderlich, da die Validierung des Tokens über kryptografische Mittel erfolgt, ohne dass der Authentifizierungsdienst kontaktiert werden muss. Dies macht die Auswertung der Token effizienter, macht es jedoch unmöglich, Zugriffsrechte für die Lebensdauer eines Tokens zu widerrufen.

Ohne häufiges Aktualisieren ist es sehr schwierig, Zugriffsrechte zu entfernen, sobald sie einem Token gewährt wurden. Wenn Sie die Lebensdauer eines Tokens auf eine Woche festlegen, müssen Sie wahrscheinlich ein anderes Mittel implementieren, um beispielsweise das Löschen eines Benutzerkontos, das Ändern eines Kennworts (oder ein anderes Ereignis, das eine erneute Anmeldung erfordert) und eine Änderung der Zugriffsberechtigungen zu behandeln für den Benutzer.

Halten Sie sich also an die häufigen Aktualisierungsintervalle. Einmal alle 15 Minuten sollte nicht ausreichen, um die Leistung Ihres Authentifizierungsdienstes zu beeinträchtigen.

Bearbeiten 18. November 2019: Gemäß dem Kommentar von @Rishabh Poddar sollten Sie eine neue Aktualisierung generieren Token jedes Mal, wenn der alte verwendet wird. Weitere Informationen finden Sie in dieser ausführlichen Diskussion zum Sitzungsmanagement.

Sie sollten das Token alle 15 Minuten aktualisieren, müssen den Benutzer jedoch nicht erneut authentifizieren lassen.

• Geben Sie nach der Authentifizierung eine JWT aus, die für 15 gültig ist Minuten.
• Lassen Sie den Client das Token aktualisieren, wenn es abgelaufen ist. Wenn dies innerhalb von sieben Tagen erfolgt, kann eine neue JWT ohne erneute Authentifizierung abgerufen werden.
• Nachdem eine Sitzung sieben Tage lang inaktiv war, muss eine Authentifizierung durchgeführt werden, bevor ein neues JWT-Token ausgegeben wird.

Auf diese Weise können Sie beispielsweise eine Authentifizierung anfordern, nachdem ein Benutzer sein Kennwort geändert hat.

Sie können das Zugriffstoken für 7 Tage konfigurieren lassen, wenn sich der Benutzer authentifiziert. In Bezug auf die Sicherheit ist dies jedoch nicht die beste Vorgehensweise, da es schwieriger ist, den Zugriff bei Bedarf zu widerrufen. Natürlich hängt es von Ihren Anforderungen ab, aber von den Es wird empfohlen, auch das Aktualisierungstoken abzurufen und es zu verwenden, um das Zugriffstoken in jedem Zeitraum zu aktualisieren.

Mein Setup ist ..

Wenn sich jemand anmeldet, generieren Sie eine JWT mit einer Exp von 5 Tagen und einem benutzerdefinierten Feld. Verwenden Sie Exp von 10 Minuten.

Wenn jemand eine erstellt authentifizierte Anfrage, die useExp muss in der Zukunft sein, es sei denn, sie fragen nach einem neuen Token.

Wenn jemand eine authentifizierte Anfrage nach einem neuen Token stellt, kann die useExp in der Vergangenheit liegen, aber die exp muss in der Zukunft sein. Wenn dies gültig ist, generiere ich ihnen ein neues Token, als ob sie sich gerade angemeldet hätten.

Wenn beide Exps in der Vergangenheit liegen, müssen sie eine nicht authentifizierte Anfrage stellen, um sich mit ihrer E-Mail-Adresse und ihrem Passwort anzumelden. P. >

Anscheinend verwenden Sie JWTs für die Sitzungsverwaltung. Was Sie ringen, ist ein typisches Problem, das bei diesem Authentifizierungsschema auftritt. JWTs sind nicht ideal für Anforderungen an das Sitzungsmanagement. Sie benötigen verschiedene Tricks, um die Sitzung länger am Leben zu halten (wie andere beschrieben), um Rechte zu widerrufen oder sich abzumelden. In diesem Artikel wird beschrieben, welche Kompromisse Sie bei diesem Setup eingehen müssen.

Wenn Sie mit den Kompromissen leben können, sind JWTs für die Sitzungsverwaltung in Ordnung. Wenn Sie eine genauere Steuerung benötigen, werfen Sie einen Blick auf Cookie-basierte Sitzungsverwaltungsschemata.

Normalerweise haben Sie für JWTs ein Zugriffstoken , das ~ 15 Minuten gültig ist, und ein Aktualisierungstoken , das länger gültig ist (z. B. 24 Stunden).

Um auf API-Endpunkte zuzugreifen, sendet der Browser nur das access -Token. Wenn es einen 401-HTTP-Status erhält, aktualisiert es sein Token, indem es das Token refresh an einen angegebenen Endpunkt sendet, zwei neue Token (sowohl Aktualisierung als auch Zugriff) abruft und fortfährt.

Hier ist das Wunderbare. Beide Token haben ein Ablaufdatum, beide Token sind signiert. Daher sollten Sie immer alle Token (unabhängig von Zugriff oder Aktualisierung) mit derselben Logik validieren, bevor Sie eine tokenspezifische Validierung durchführen.

Für diejenigen, die zwei JWTs ( @keithRozario @Sjoerd) oder ein JWT, aber zwei Felder ( @Michael Baldry @ erwähnt haben) Laurens Rietveld):

Nennen wir die beiden JWT- oder zwei Felder Zugriffstoken und Aktualisierungstoken .

Wenn der Hacker das Zugriffstoken irgendwie erhält, ist es sehr wahrscheinlich, dass das Aktualisierungstoken ebenfalls durchgesickert ist und der Hacker das Zugriffstoken mithilfe des Aktualisierungstokens anfordern kann. In diesem Sinne hilft der kurze Ablauf des Zugriffstokens hier nicht viel.

Jemand schlug vor, auf der Serverseite eine Sperrliste zu führen, damit jede Anforderung zum Aktualisieren des Tokens erfolgen sollte überprüft werden. Einer der Hauptgründe, warum Benutzer JWT verwenden, ist, dass der Server die Sitzung nicht warten muss, damit sie skalierbarer ist. Bricht die Idee, die Sperrliste beizubehalten, diesen Vorteil nicht?

Eine Möglichkeit, die ich mir vorstellen kann, besteht darin, dem Zugriffstoken ein weiteres Feld hinzuzufügen, um die Aktualisierung des Tokens auf beispielsweise 30 Minuten zu beschränken. So kann der Verlust auch dann gemindert werden, wenn sowohl das Zugriffstoken als auch das Aktualisierungstoken durchgesickert sind. Aber ich bin mir nicht sicher, ob es eine gute Praxis ist oder nicht.