JWT (JSON Web Token) automatische Verlängerung des Ablaufs


509

Ich möchte die JWT-basierte Authentifizierung für unsere neue REST-API implementieren. Ist es jedoch möglich, den Ablauf automatisch zu verlängern, da er im Token festgelegt ist? Ich möchte nicht, dass sich Benutzer alle X Minuten anmelden müssen, wenn sie die Anwendung in diesem Zeitraum aktiv genutzt haben. Das wäre ein großer UX-Fehler.

Wenn Sie jedoch den Ablauf verlängern, wird ein neues Token erstellt (und das alte ist noch gültig, bis es abläuft). Und nach jeder Anfrage ein neues Token zu generieren, klingt für mich albern. Klingt nach einem Sicherheitsproblem, wenn mehr als ein Token gleichzeitig gültig ist. Natürlich könnte ich die alte gebrauchte mit einer schwarzen Liste ungültig machen, aber ich müsste die Token speichern. Und einer der Vorteile von JWT ist kein Speicher.

Ich habe herausgefunden, wie Auth0 es gelöst hat. Sie verwenden nicht nur ein JWT-Token, sondern auch ein Aktualisierungstoken: https://docs.auth0.com/refresh-token

Um dies zu implementieren (ohne Auth0), müsste ich Aktualisierungstoken speichern und deren Ablauf beibehalten. Was ist dann der wahre Vorteil? Warum nicht nur ein Token (nicht JWT) haben und den Ablauf auf dem Server behalten?

Gibt es noch andere Möglichkeiten? Ist die Verwendung von JWT für dieses Szenario nicht geeignet?


1
Tatsächlich gibt es wahrscheinlich kein Sicherheitsproblem mit vielen gültigen Token gleichzeitig ... Es gibt tatsächlich unendlich viele gültige Token ... Warum also ein Aktualisierungstoken? Ich werde sie nach jeder Anfrage neu generieren, es sollte eigentlich kein Problem sein.
Maryo

1
Für SPA, überprüfen
Sie

2
@maryo Ich denke, dass (möglicherweise) Hunderte oder Tausende von nicht verwendeten gültigen JWTs zu einem bestimmten Zeitpunkt Ihren Angriffs-Footprint erhöhen und ein Sicherheitsrisiko darstellen. Meiner Meinung nach sollten Zeugen Jehovas sorgfältig ausgestellt werden, da sie in gewisser Weise Zugangsmarken mit den Schlüsseln zum Schloss sind.
Java-Addict301

Antworten:


590

Ich arbeite bei Auth0 und war am Design der Funktion zum Aktualisieren von Token beteiligt.

Es hängt alles von der Art der Anwendung ab und hier ist unser empfohlener Ansatz.

Web Applikationen

Ein gutes Muster besteht darin, das Token vor Ablauf zu aktualisieren.

Stellen Sie den Token-Ablauf auf eine Woche ein und aktualisieren Sie den Token jedes Mal, wenn der Benutzer die Webanwendung öffnet, und alle eine Stunde. Wenn ein Benutzer die Anwendung länger als eine Woche nicht öffnet, muss er sich erneut anmelden. Dies ist eine akzeptable Webanwendung UX.

Um das Token zu aktualisieren, benötigt Ihre API einen neuen Endpunkt, der eine gültige, nicht abgelaufene JWT empfängt und dieselbe signierte JWT mit dem neuen Ablauffeld zurückgibt. Dann speichert die Webanwendung das Token irgendwo.

Mobile / native Anwendungen

Die meisten nativen Anwendungen melden sich einmal und nur einmal an.

Die Idee ist, dass das Aktualisierungstoken niemals abläuft und immer gegen ein gültiges JWT ausgetauscht werden kann.

Das Problem mit einem Token, das niemals abläuft, ist, dass es niemals niemals bedeutet. Was machst du, wenn du dein Handy verlierst? Es muss also für den Benutzer irgendwie identifizierbar sein und die Anwendung muss eine Möglichkeit bieten, den Zugriff zu widerrufen. Wir haben uns entschieden, den Namen des Geräts zu verwenden, z. B. "Maryos iPad". Dann kann der Benutzer zur Anwendung gehen und den Zugriff auf "Maryos iPad" widerrufen.

Ein anderer Ansatz besteht darin, das Aktualisierungstoken für bestimmte Ereignisse zu widerrufen. Ein interessantes Ereignis ist das Ändern des Passworts.

Wir glauben, dass JWT für diese Anwendungsfälle nicht nützlich ist, daher verwenden wir eine zufällig generierte Zeichenfolge und speichern sie auf unserer Seite.


42
Wenn das Token für den von Webanwendungen empfohlenen Ansatz eine Woche lang gültig ist, geht es uns dann nicht darum, dass jemand das Token abfängt und es dann so lange verwenden kann? Haftungsausschluss: Ich weiß nicht genau, wovon ich spreche.
user12121234

30
@wbeange Ja, das Abfangen ist ein Problem, auch bei Cookies. Sie sollten https verwenden.
José F. Romaniello

15
@ JoséF.Romaniello In Ihrem Webanwendungsbeispiel macht alles für mich Sinn, außer dass ich das Token speichern muss. Ich dachte, die Schönheit von JWT sei die zustandslose Authentifizierung - was bedeutet, dass die Webanwendung das Token NICHT speichern muss, wenn es signiert ist. Ich würde denken, der Server könnte einfach die Gültigkeit des Tokens überprüfen, sicherstellen, dass es innerhalb des Ablaufzeitraums liegt, und dann ein erneuertes JWT-Token ausstellen. Könnten Sie das bitte näher erläutern? Vielleicht verstehe ich JWTs einfach noch nicht genug.
Lo-Tan

7
Zwei Fragen / Bedenken: 1- Webanwendungsfall: Warum kann abgelaufenes Token nicht aktualisiert werden? Angenommen, wir legen einen kurzen Ablauf (1 Stunde) fest und rufen den Backend-Server erneut an, wenn ein Token abläuft, wie Sie sagten. 2- Gibt es Sicherheitsbedenken beim Speichern des Hash-Passworts (mit zufälligem Salt) im Token? Die Idee ist, dass der Back-End-Server, wenn er vorhanden ist, das in der Datenbank gespeicherte Kennwort überprüfen kann, wenn er nach einer Verlängerung gefragt wird, und die Anforderung ablehnen kann, wenn die Kennwörter nicht übereinstimmen. Dies würde die Kennwortänderung der Mobile / Native-App abdecken und die Erweiterung der Lösung auf den Anwendungsfall Mobile ermöglichen.
Psamaan

7
-1 Das Offenlegen einer öffentlichen API, die jedes Token blind neu signiert, um seinen Validierungszeitraum zu verlängern, ist fehlerhaft. Jetzt haben alle Ihre Token einen effektiven unendlichen Ablauf. Der Vorgang des Signierens eines Tokens sollte die entsprechenden Authentifizierungsprüfungen für jeden Anspruch enthalten, der zum Zeitpunkt des Signierens in diesem Token geltend gemacht wurde.
Phil

69

In dem Fall, in dem Sie die Authentifizierung selbst durchführen (dh keinen Anbieter wie Auth0 verwenden), kann Folgendes funktionieren:

  1. Stellen Sie ein JWT-Token mit einem relativ kurzen Ablauf aus, z. B. 15 Minuten.
  2. Die Anwendung überprüft das Ablaufdatum des Tokens vor jeder Transaktion, für die ein Token erforderlich ist (das Token enthält das Ablaufdatum). Wenn das Token abgelaufen ist, fordert es die API zunächst auf, das Token zu aktualisieren (dies erfolgt transparent für die UX).
  3. Die API erhält eine Token-Aktualisierungsanforderung, überprüft jedoch zuerst die Benutzerdatenbank, um festzustellen, ob für dieses Benutzerprofil ein 'reauth'-Flag gesetzt wurde (das Token kann eine Benutzer-ID enthalten). Wenn das Flag vorhanden ist, wird die Tokenaktualisierung verweigert, andernfalls wird ein neues Token ausgegeben.
  4. Wiederholen.

Das Flag 'reauth' im Datenbank-Backend wird gesetzt, wenn der Benutzer beispielsweise sein Kennwort zurückgesetzt hat. Das Flag wird entfernt, wenn sich der Benutzer das nächste Mal anmeldet.

Angenommen, Sie haben eine Richtlinie, nach der sich ein Benutzer mindestens alle 72 Stunden anmelden muss. In diesem Fall überprüft Ihre API-Token-Aktualisierungslogik auch das letzte Anmeldedatum des Benutzers aus der Benutzerdatenbank und verweigert / lässt die Token-Aktualisierung auf dieser Basis zu.


7
Ich denke nicht, dass dies sicher wäre. Wenn ich ein Angreifer wäre und Ihr Token gestohlen und an den Server gesendet hätte, würde der Server überprüfen, ob das Flag auf true gesetzt ist, was großartig ist, da es eine Aktualisierung blockieren würde. Ich denke, das Problem wäre, wenn das Opfer sein Passwort ändern würde, würde das Flag auf false gesetzt und jetzt kann der Angreifer dieses ursprüngliche Token zum Aktualisieren verwenden.
user2924127

6
@ user2924127 Keine Authentifizierungslösung ist perfekt und es wird immer Kompromisse geben. Wenn ein Angreifer in der Lage ist, "Ihren Token zu stehlen", müssen Sie sich möglicherweise um größere Probleme sorgen. Das Festlegen einer maximalen Token-Lebensdauer wäre eine nützliche Änderung der oben genannten Punkte.
IanB

27
Anstatt ein anderes Feld in der Datenbank zu haben, das Reauth-Flag, können Sie Hash (bcrypt_password_hash) in das Token aufnehmen. Wenn Sie das Token aktualisieren, bestätigen Sie einfach, ob der Hash (bcrypt_password_hash) einem Wert aus dem Token entspricht. Um die Token-Aktualisierung zu verweigern, muss nur der Passwort-Hash aktualisiert werden.
Bas

4
@bas, wenn ich an Optimierungen und Leistung denke, denke ich, dass die Validierung des Passwort-Hashs redundant wäre und mehr Auswirkungen auf den Server hätte. Erhöhen Sie die Größe des Tokens, damit die Signaturfirma / -validierung mehr Zeit in Anspruch nimmt. Zusätzliche Hash-Berechnungen für den Server für das Passwort. Mit dem zusätzlichen Feldansatz validieren Sie einfach in der Neuberechnung mit einem einfachen Booleschen Wert. Datenbankaktualisierungen sind für das zusätzliche Feld weniger häufig, aber häufiger für Tokenaktualisierungen. Und Sie erhalten den optionalen Service, individuelle Neuanmeldungen für jede vorhandene Sitzung (Mobil, Web usw.) zu erzwingen.
Le0diaz

6
Ich denke, der erste Kommentar von user2924127 ist tatsächlich falsch. Wenn das Kennwort geändert wird, wird das Konto als erneut authentifizierbar markiert, sodass alle vorhandenen abgelaufenen Token ungültig sind.
Ralph

15

Ich habe herumgebastelt, als ich unsere Anwendungen mit RESTful apis im Backend auf HTML5 verschoben habe. Die Lösung, die ich gefunden habe, war:

  1. Der Client erhält nach erfolgreicher Anmeldung ein Token mit einer Sitzungszeit von 30 Minuten (oder unabhängig von der üblichen serverseitigen Sitzungszeit).
  2. Ein clientseitiger Timer wird erstellt, um einen Dienst aufzurufen, um das Token vor Ablauf seiner Zeit zu erneuern. Das neue Token ersetzt die in zukünftigen Aufrufen vorhandenen.

Wie Sie sehen können, reduziert dies die häufigen Anforderungen für Aktualisierungstoken. Wenn der Benutzer den Browser / die App schließt, bevor der Aufruf zum Erneuern des Tokens ausgelöst wird, läuft das vorherige Token rechtzeitig ab und der Benutzer muss sich erneut anmelden.

Eine kompliziertere Strategie kann implementiert werden, um Benutzerinaktivität zu berücksichtigen (z. B. vernachlässigte geöffnete Browser-Registerkarte). In diesem Fall sollte der Aufruf des Erneuerungstokens die erwartete Ablaufzeit enthalten, die die definierte Sitzungszeit nicht überschreiten sollte. Die Anwendung muss die letzte Benutzerinteraktion entsprechend verfolgen.

Ich mag die Idee, einen langen Ablauf festzulegen, nicht, daher funktioniert dieser Ansatz möglicherweise nicht gut mit nativen Anwendungen, die eine weniger häufige Authentifizierung erfordern.


1
Was ist, wenn der Computer angehalten wurde? Der Timer zählt noch bis zum Ablauf, aber der Token war tatsächlich bereits abgelaufen. Timer funktioniert in diesen Situationen nicht
Alex Parij

@AlexParij Sie würden mit einer festen Zeit vergleichen, so etwas wie: stackoverflow.com/a/35182296/1038456
Aparajita

2
Das Zulassen, dass der Client ein neues Token mit einem bevorzugten Ablaufdatum anfordert, riecht für mich nach einem Sicherheitsrisiko.
Java-Addict301

14

Eine alternative Lösung zum Ungültigmachen von JWTs ohne zusätzlichen sicheren Speicher im Backend besteht darin, eine neue jwt_versionGanzzahlspalte in der Benutzertabelle zu implementieren. Wenn der Benutzer vorhandene Token abmelden oder ablaufen lassen möchte, erhöht er einfach diejwt_version Feld.

Codieren Sie beim Generieren eines neuen JWT die jwt_version in die JWT-Nutzdaten und erhöhen Sie den Wert optional im Voraus, wenn die neue JWT alle anderen ersetzen soll.

Bei der Validierung des JWT wird das jwt_versionFeld neben dem verglichen user_idund die Autorisierung wird nur erteilt, wenn sie übereinstimmt.


1
Dies hat Probleme mit mehreren Geräten. Wenn Sie sich auf einem Gerät abmelden, wird es im Wesentlichen überall abgemeldet. Recht?
Sam Washburn

4
Hey, das ist vielleicht kein "Problem", abhängig von Ihren Anforderungen, aber Sie haben Recht; Dies unterstützt nicht die Sitzungsverwaltung pro Gerät.
Ollie Bennett

Bedeutet dies nicht, dass die jwt_version serverseitig gespeichert werden muss, damit das Authentifizierungsschema "sitzungsähnlich" wird und den grundlegenden Zweck von JWTs zunichte macht?
ChetPrickles vor

8

Gute Frage - und die Frage selbst enthält eine Fülle von Informationen.

Der Artikel Token aktualisieren: Wann sie verwendet werden und wie sie mit JWTs interagieren, bietet eine gute Idee für dieses Szenario. Einige Punkte sind: -

  • Aktualisierungstoken enthalten die Informationen, die zum Abrufen eines neuen Zugriffstokens erforderlich sind.
  • Aktualisierungstoken können ebenfalls ablaufen, sind jedoch ziemlich langlebig.
  • Aktualisierungstoken unterliegen normalerweise strengen Speicheranforderungen, um sicherzustellen, dass sie nicht auslaufen.
  • Sie können auch vom Autorisierungsserver auf die schwarze Liste gesetzt werden.

Schauen Sie sich auch auth0 / angle-jwt anglejs an

Für die Web-API. Lesen Sie OAuth-Aktualisierungstoken in AngularJS App mithilfe von ASP .NET Web API 2 und Owin aktivieren


Vielleicht habe ich es falsch gelesen ... Aber ein Artikel mit einem Titel, der mit "Token aktualisieren ..." beginnt, enthält nichts über Aktualisierungstoken, außer dem, was Sie hier erwähnt haben.
Ievgen Martynov

8

Ich habe dies tatsächlich in PHP implementiert, indem ich den Guzzle-Client verwendet habe, um eine Client-Bibliothek für die API zu erstellen, aber das Konzept sollte für andere Plattformen funktionieren.

Grundsätzlich stelle ich zwei Token aus, einen kurzen (5 Minuten) und einen langen, der nach einer Woche abläuft. Die Clientbibliothek verwendet Middleware, um eine Aktualisierung des kurzen Tokens zu versuchen, wenn sie eine 401-Antwort auf eine Anforderung erhält. Anschließend wird die ursprüngliche Anforderung erneut versucht, und wenn eine Aktualisierung möglich war, wird die richtige Antwort transparent für den Benutzer angezeigt. Wenn dies fehlschlägt, wird der 401 nur an den Benutzer gesendet.

Wenn das kurze Token abgelaufen ist, aber immer noch authentisch und das lange Token gültig und authentisch ist, wird das kurze Token mithilfe eines speziellen Endpunkts auf dem Dienst aktualisiert, den das lange Token authentifiziert (dies ist das einzige, wofür es verwendet werden kann). Das kurze Token wird dann verwendet, um ein neues langes Token zu erhalten, wodurch es jedes Mal um eine weitere Woche verlängert wird, wenn das kurze Token aktualisiert wird.

Dieser Ansatz ermöglicht es uns auch, den Zugriff innerhalb von höchstens 5 Minuten zu widerrufen, was für unsere Verwendung akzeptabel ist, ohne dass eine schwarze Liste von Token gespeichert werden muss.

Späte Bearbeitung: Beim erneuten Lesen in diesem Monat, nachdem es in meinem Kopf frisch war, sollte ich darauf hinweisen, dass Sie den Zugriff beim Aktualisieren des kurzen Tokens widerrufen können, da dies die Möglichkeit für teurere Anrufe bietet (z. B. Aufruf der Datenbank, um festzustellen, ob der Benutzer dies tut wurde gesperrt), ohne bei jedem einzelnen Anruf bei Ihrem Dienst dafür zu bezahlen.


8

Im Folgenden finden Sie die Schritte zum Widerrufen Ihres JWT-Zugriffstokens:

1) Wenn Sie sich anmelden, senden Sie 2 Token (Zugriffstoken, Aktualisierungstoken) als Antwort an den Client.
2) Das Zugriffstoken hat weniger Ablaufzeit und das Aktualisieren hat eine lange Ablaufzeit.
3) Der Client (Front-End) speichert das Aktualisierungstoken in seinem lokalen Speicher und das Zugriffstoken in Cookies.
4) Der Client verwendet das Zugriffstoken zum Aufrufen von apis. Wenn es jedoch abläuft, wählen Sie das Aktualisierungstoken aus dem lokalen Speicher aus und rufen Sie die Authentifizierungsserver-API auf, um das neue Token zu erhalten.
5) Auf Ihrem Authentifizierungsserver wird eine API angezeigt, die ein Aktualisierungstoken akzeptiert, deren Gültigkeit überprüft und ein neues Zugriffstoken zurückgibt.
6) Sobald das Aktualisierungstoken abgelaufen ist, wird der Benutzer abgemeldet.

Bitte lassen Sie mich wissen, wenn Sie weitere Details benötigen, ich kann den Code (Java + Spring Boot) auch teilen.


Könnten Sie bitte Ihren Projektlink teilen, wenn Sie ihn in GitHub haben?
Arun Kumar N


6

jwt-autorefresh

Wenn Sie einen Knoten (React / Redux / Universal JS) verwenden, können Sie diesen installieren npm i -S jwt-autorefresh.

Diese Bibliothek plant die Aktualisierung von JWT-Token mit einer vom Benutzer berechneten Anzahl von Sekunden vor Ablauf des Zugriffstokens (basierend auf dem im Token codierten Exp-Anspruch). Es verfügt über eine umfangreiche Testsuite und überprüft einige Bedingungen, um sicherzustellen, dass seltsame Aktivitäten von einer beschreibenden Meldung zu Fehlkonfigurationen in Ihrer Umgebung begleitet werden.

Vollständige Beispielimplementierung

import autorefresh from 'jwt-autorefresh'

/** Events in your app that are triggered when your user becomes authorized or deauthorized. */
import { onAuthorize, onDeauthorize } from './events'

/** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */
const refresh = () => {
  const init =  { method: 'POST'
                , headers: { 'Content-Type': `application/x-www-form-urlencoded` }
                , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token`
                }
  return fetch('/oauth/token', init)
    .then(res => res.json())
    .then(({ token_type, access_token, expires_in, refresh_token }) => {
      localStorage.access_token = access_token
      localStorage.refresh_token = refresh_token
      return access_token
    })
}

/** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */
const leadSeconds = () => {
  /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */
  const jitter = Math.floor(Math.random() * 30)

  /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */
  return 60 + jitter
}

let start = autorefresh({ refresh, leadSeconds })
let cancel = () => {}
onAuthorize(access_token => {
  cancel()
  cancel = start(access_token)
})

onDeauthorize(() => cancel())

Haftungsausschluss: Ich bin der Betreuer


Frage dazu, ich habe die Dekodierungsfunktion gesehen, die es verwendet. Wird davon ausgegangen, dass das JWT ohne Verwendung eines Geheimnisses dekodiert werden kann? Funktioniert es mit JWT, die mit einem Geheimnis signiert wurden?
Gian Franco Zabarino

3
Ja, die Dekodierung ist eine reine Clientdekodierung und sollte das Geheimnis nicht kennen. Das Geheimnis wird verwendet, um das JWT-Token serverseitig zu signieren, um zu überprüfen, ob Ihre Signatur ursprünglich zum Generieren des JWT verwendet wurde und niemals vom Client verwendet werden sollte. Die Magie von JWT besteht darin, dass seine Nutzdaten clientseitig dekodiert werden können und die darin enthaltenen Ansprüche verwendet werden können, um Ihre Benutzeroberfläche ohne das Geheimnis zu erstellen. Das einzige, wofür es jwt-autorefreshdekodiert wird, ist das Extrahieren des expAnspruchs, damit bestimmt werden kann, wie weit die nächste Aktualisierung geplant ist.
Cchamberlain

1
Oh gut zu wissen, etwas ergab keinen Sinn, aber jetzt schon. Danke für die Antwort.
Gian Franco Zabarino

4

Ich habe dieses Problem durch Hinzufügen einer Variablen in den Token-Daten gelöst:

softexp - I set this to 5 mins (300 seconds)

Ich habe die expiresInOption auf die gewünschte Zeit eingestellt, bevor der Benutzer erneut angemeldet werden muss. Meins ist auf 30 Minuten eingestellt. Dies muss größer sein als der Wert von softexp.

Wenn meine clientseitige App eine Anforderung an die Server-API sendet (wo ein Token erforderlich ist, z. B. eine Kundenlistenseite), prüft der Server anhand des ursprünglichen Ablaufwerts ( expiresIn) , ob das übermittelte Token noch gültig ist oder nicht . Wenn es nicht gültig ist, antwortet der Server mit einem bestimmten Status für diesen Fehler, z. INVALID_TOKEN.

Wenn das Token basierend auf dem expiredInWert weiterhin gültig ist, den Wert jedoch bereits überschritten softexphat, antwortet der Server mit einem separaten Status für diesen Fehler, z. EXPIRED_TOKEN::

(Math.floor(Date.now() / 1000) > decoded.softexp)

Wenn auf der Clientseite eine EXPIRED_TOKENAntwort empfangen wurde , sollte das Token automatisch erneuert werden, indem eine Erneuerungsanforderung an den Server gesendet wird. Dies ist für den Benutzer transparent und wird automatisch für die Client-App erledigt.

Die Erneuerungsmethode auf dem Server muss prüfen, ob das Token noch gültig ist:

jwt.verify(token, secret, (err, decoded) => {})

Der Server lehnt die Erneuerung von Token ab, wenn die oben beschriebene Methode fehlgeschlagen ist.


Diese Strategie sieht gut aus. Aber ich denke, sollte mit einer Art "maximaler Anzahl von Erneuerungen" ergänzt werden, weil (vielleicht) eine Benutzersitzung für immer am Leben sein kann.
Juan Ignacio Barisich

1
Sie können eine hardExp-Variable in den Token-Daten festlegen, um ein maximales Datum festzulegen, an dem das Ablaufen des Tokens erzwungen werden soll, oder einen Zähler, der bei jeder Erneuerung des Tokens dekrementiert wird, wodurch die Anzahl der gesamten Token-Erneuerungen begrenzt wird.
James A

1
das ist richtig. Ich halte das für ein "Muss".
Juan Ignacio Barisich

2

Wie wäre es mit diesem Ansatz:

  • Für jede Clientanforderung vergleicht der Server die Ablaufzeit des Tokens mit (currentTime - lastAccessTime).
  • Wenn expirationTime <(currentTime - lastAccessedTime) ist , wird die letzte lastAccessedTime in currentTime geändert.
  • Bei Inaktivität im Browser für eine Zeitdauer, die expirationTime überschreitet, oder bei geschlossenem Browserfenster und expirationTime> (currentTime - lastAccessedTime) kann der Server das Token ablaufen lassen und den Benutzer auffordern, sich erneut anzumelden .

In diesem Fall benötigen wir keinen zusätzlichen Endpunkt zum Aktualisieren des Tokens. Würde mich über jeden Feedack freuen.


Ist es heutzutage eine gute Wahl? Die Implementierung sieht ziemlich einfach aus.
b.ben

4
Wo speichern Sie in diesem Fall lastAccessedTime? Sie müssen dies im Backend und auf Anfrage tun, damit es zu einer nicht gewünschten zustandsbehafteten Lösung wird.
Antgar9

2

Heutzutage entscheiden sich viele Menschen für das Sitzungsmanagement mit JWTs, ohne zu wissen, was sie aus Gründen der wahrgenommenen Einfachheit aufgeben . Meine Antwort geht auf den 2. Teil der Fragen ein:

Was ist dann der wahre Vorteil? Warum nicht nur ein Token (nicht JWT) haben und den Ablauf auf dem Server behalten?

Gibt es noch andere Möglichkeiten? Ist die Verwendung von JWT für dieses Szenario nicht geeignet?

JWTs können das grundlegende Sitzungsmanagement mit einigen Einschränkungen unterstützen. Als selbstbeschreibende Token benötigen sie keinen Status auf der Serverseite. Das macht sie ansprechend. Wenn der Dienst beispielsweise keine Persistenzschicht hat, muss er nicht nur für die Sitzungsverwaltung eingefügt werden.

Staatenlosigkeit ist jedoch auch die Hauptursache für ihre Mängel. Da sie nur einmal mit festem Inhalt und Ablauf ausgegeben werden, können Sie mit einem typischen Sitzungsverwaltungs-Setup nicht die gewünschten Aktionen ausführen.

Sie können sie nämlich nicht bei Bedarf ungültig machen. Dies bedeutet, dass Sie keine sichere Abmeldung implementieren können, da bereits ausgegebene Token nicht ablaufen können. Sie können auch kein Leerlaufzeitlimit implementieren dem gleichen Grund . Eine Lösung besteht darin, eine schwarze Liste zu führen, die jedoch den Status einführt.

Ich habe einen Beitrag geschrieben, in dem diese Nachteile ausführlicher erläutert werden. Um es klar auszudrücken, können Sie diese umgehen, indem Sie mehr Komplexität hinzufügen (Schiebesitzungen, Aktualisierungstoken usw.).

Für andere Optionen empfehle ich dringend die Verwendung einer Cookie-basierten Sitzungsverwaltungslösung, wenn Ihre Kunden nur über einen Browser mit Ihrem Dienst interagieren. Ich habe auch eine Listenauthentifizierungsmethode zusammengestellt, die derzeit im Web weit verbreitet ist.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.