Frage:
Ist das Aktualisieren eines abgelaufenen JWT-Tokens eine gute Strategie?
Guillaume Vincent
2016-04-03 16:09:51 UTC
view on stackexchange narkive permalink

Wenn ich Best Practices verstehe, hat JWT normalerweise ein kurzlebiges Ablaufdatum (~ 15 Minuten). Wenn ich nicht möchte, dass sich mein Benutzer alle 15 Minuten anmeldet, sollte ich mein Token alle 15 Minuten aktualisieren.

Ich muss also eine gültige Sitzung für 7 Tage aufrechterhalten (UX-Sicht) Ich habe zwei Lösungen:

  • Verwenden Sie ein langlebiges JSON-Web-Token (1 Woche) - schlechte Praxis?
  • Erhalten Sie ein neues JSON-Web-Token, nachdem das alte abgelaufen ist ( JWT 15 Minuten, Aktualisierung während 1 Woche zulässig)

Ich erzwinge die Verwendung von HTTPS.

Der JWT-Standard spricht nicht über erfrischende Token. Ist das Aktualisieren eines abgelaufenen Tokens eine gute Strategie?

Sieben antworten:
#1
+42
Neil Smithline
2016-04-03 23:50:32 UTC
view on stackexchange narkive permalink

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.

damit ich ein abgelaufenes Token aktualisieren kann?warum empfehlen die Leute nicht?
-1
Ohne Referenz ist es schwer zu verstehen, warum etwas empfohlen wurde.Haben Sie Referenzen?Der Punkt des Aktualisierungstokens besteht darin, den Widerruf von Zugriffsrechten zuzulassen, ohne den Authentifizierungsdienst zu häufig zu treffen.Sie können das Token aktualisieren (das eine Zugriffsprüfung durchführt), ohne sich erneut authentifizieren zu müssen.
Ok, also Aktualisierungstoken können ebenfalls ablaufen, sind aber langlebig.Sie werden nur zum Widerruf von Zugriffsrechten verwendet.Diese Token können also zum Aktualisieren eines abgelaufenen Tokens verwendet werden.
Ja.Vielleicht hilft dies https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
Wenn das Aktualisierungstoken abläuft, ist eine erneute Authentifizierung erforderlich.
Was passiert, wenn der Benutzer die App 30 Minuten lang schließt?Wie kann ich alle 15 Minuten ein neues Token abrufen, wenn die App nicht ausgeführt wird?
@AliSherafat - Solange das Aktualisierungstoken gespeichert und noch gültig ist, kann die App ein neues Zugriffstoken erhalten.Wenn das Aktualisierungstoken abgelaufen ist, wurde der Benutzer aufgrund seines Leerlaufs abgemeldet und muss sich erneut anmelden.
Verstanden, aber sollte das Aktualisierungstoken aktualisiert werden?Wenn ich die Lebensdauer auf 1 Tag einstelle, verwendet ein Benutzer die App noch, muss ich ihn abmelden?Oder die Lebensdauer des Aktualisierungstokens während der Verwendung verlängern?
@AliSherafat Ich glaube nicht, dass es eine Standardmethode zum Aktualisieren des Aktualisierungstokens gibt.Wenn sowohl Zugriffstoken als auch Aktualisierungstoken ablaufen, wird der Benutzer abgemeldet.Wenn Ihr Aktualisierungstoken eine 24-Stunden-TTL hat, muss Ihre Website oder Ihr Dienst einmal täglich erneut authentifiziert werden.Das ist ziemlich häufig.
Es wird nicht empfohlen, ein abgelaufenes JWT-Token zu aktualisieren.Sie sollen aus Sicherheitsgründen ablaufen, und ich glaube nicht einmal, dass es möglich ist, JWT-Token zu aktualisieren und abzulaufen, je nachdem, wie ich weiß, dass sie generiert wurden.Pro Aktion sollte ein neues Token generiert werden, und jeder JWT-Anspruch sollte eine eindeutige Kennung enthalten, um die API-Aufrufe zu verfolgen.
Um ein bisschen mehr Informationen hinzuzufügen: Die ideale Methode gemäß [RFC 6819] (https://tools.ietf.org/html/rfc6819#section-5.2.2.3) besteht darin, die Aktualisierungstoken bei ihrer Verwendung ständig zu ändern - dies bietetdas maximale Maß an Sicherheit, wie in [diesem zweiteiligen Blog-Beitrag] (https://supertokens.io/blog/all-you-need-to-know-about-user-session-security) gezeigt.
Danke @RishabhPoddar - Ich habe den Beitrag aktualisiert.
#2
+14
Sjoerd
2016-04-12 14:10:46 UTC
view on stackexchange narkive permalink

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.
/ ul>

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

Es ist die Lösung, die ich derzeit verwende: "Lassen Sie den Client das Token aktualisieren, wenn es abgelaufen ist." Meine Frage lautet: Ist das Aktualisieren eines abgelaufenen Tokens eine gute Strategie?
Der Client aktualisiert das alte Token nicht in dem Sinne, dass er das alte Token verwendet, um ein neues zu erhalten.Stattdessen weiß die Authentifizierungsschicht, dass der Client kürzlich angemeldet wurde, und gibt ihm ein neues Token.Sie können dies implementieren, indem Sie zwei JWTs verwenden, von denen eine 15 Minuten und eine 7 Tage gültig ist.Das Token mit langer Laufzeit kann nur zum Anfordern eines Tokens mit kurzer Laufzeit verwendet werden, und das Token mit kurzer Laufzeit kann zum Zugriff auf Ihre API oder was auch immer verwendet werden.Dies ermöglicht es weiterhin, den Zugriff alle 15 Minuten zu widerrufen, während Sitzungen von 7 Tagen stattfinden.
@Sjoerd wird das die Dinge nicht zu kompliziert machen?Der Server erwartet 2 JWT .. und der Client behält 2 ..
Ich denke, die Verwendung von zwei JWTs ist eine der Optionen.Eine andere Möglichkeit wäre, 1 JWT mit einer "Exp" von 7 Tagen und einer benutzerdefinierten "ShortExp" von 15 Minuten zu verwenden.Solange Ihre Middleware beide Ablaufwerte ordnungsgemäß überprüft und das Token erneut ausgibt, wenn "shortExp" abläuft, sollte dies in Ordnung sein
Wie funktioniert das Aktualisieren eines Tokens überhaupt?Speichern Sie den Benutzernamen + das Passwort des Benutzers auf der Clientseite?
Müssen wir das Aktualisierungstoken exp erweitern, um eine 7-tägige aktive Sitzung aufrechtzuerhalten, wenn der Client die App aktiv verwendet?
@YesMan85 Nein, wir speichern keinen Benutzernamen und kein Passwort, sondern ein Aktualisierungstoken auf der Clientseite und in der Datenbank für diesen Benutzer.Wenn Benutzer zur Aktualisierung zum Server kommen, können wir sowohl das Zugriffstoken als auch das Aktualisierungstoken überprüfen, um das neue Zugriffstoken auszustellen.Das Aktualisierungstoken kann ein beliebiges zufällig generiertes alphanumerisches Zeichen sein.
Warum nicht ein langlebiges Token erstellen und es in der Datenbank zum Widerruf verfolgen?Auf diese Weise macht das Löschen des Token-Tracking-Tokens das JWT-Token effektiv ungültig und widerruft es.Ein Nachteil ist, dass Sie bei jeder Anforderung immer noch in die Datenbank gehen müssen, um sicherzustellen, dass das Token weiterhin verfolgt wird.
#3
+5
Igliv
2016-04-04 18:49:16 UTC
view on stackexchange narkive permalink

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.

Alle reden über Aktualisierungstoken, zeigen aber nicht genau, wie.Out-of-Band-Anfragen?Bei einer passiven Anwendung, die nur bei Interaktion Daten vom Server abruft, ist dies nur zeitlich möglich. In diesem Fall treten andere Probleme auf, z. B. Verbindungsprobleme, wenn eine geplante Aktualisierungsanforderung versucht wird.
Es gibt eine Reihe von Implementierungen.Hängt davon ab, welches Framework und welche Sprache Sie verwenden. Nur ein paar Beispiele: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/ https://developer.okta.com/docs/guides/refresh-tokens/use-refresh-token/
#4
+5
Michael Baldry
2017-09-14 17:43:07 UTC
view on stackexchange narkive permalink

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. >

Jede Antwort ist mit einem Aufwand für die Suche nach einem neueren Token verbunden.
Ich verstehe deinen Kommentar nicht.Was meinst du mit der Suche nach einem neueren Token?Sie werden nirgendwo auf der Serverseite gespeichert, das ist das Gute an JWT.Nehmen Sie einfach das im Authentifizierungsheader angegebene Token, überprüfen Sie, ob es gültig und nicht abgelaufen ist.Ein Sonderfall wäre ein Aktualisierungsendpunkt, der ein abgelaufenes Token zulässt. Aktivieren Sie jedoch ein zusätzliches Feld, das eine längere Ablaufzeit enthält, in dem das Token aktualisiert werden kann.Auf diese Weise vergleicht der Server nur einen Zeitstempel mit der aktuellen Zeit, es ist kaum ein Overhead.
Was ich damit meinte war, dass Sie keine Kontrolle über die Verwendung des JWT haben.Ihre Methode ist gut und alles, aber wenn das Token jemals (irgendwie) gestohlen wurde, gibt es keine Möglichkeit, die Sitzung zu beenden, da der Server seinen Status in keiner Weise widerspiegelt.Ich habe also zuvor eine ID (JTI-Feld) für Token erstellt und diese in der Datenbank gespeichert.Wenn die Datenbank kein übereinstimmendes JTI-Token enthält, wird das JWT abgelehnt, unabhängig davon, ob es abgelaufen ist oder nicht.Auf diese Weise kann ich JWT ab einem Alter von 90 Tagen ausgeben, damit sich Anwendungsbenutzer nicht über die Anmeldung ärgern. Dies hängt natürlich von der Art der Anwendung ab.
Dies gibt mir die vollständige Kontrolle über das JWT und die Sitzungen, da ich eine Sitzung jederzeit beenden kann.Ihre Methode funktioniert möglicherweise gut mit finanziellen und sensiblen Arten von Anwendungen.Für eine Chat- / Social-Anwendung wäre es nicht intuitiv, den Benutzer zu bitten, sich alle 5 Tage anzumelden.Ich denke, der beste Weg ist, den Benutzer wissen zu lassen, wann die Sitzung endet, und ihm zu ermöglichen, das Token beispielsweise 60 bis 10 Minuten vor Ablauf manuell zu aktualisieren.Der Overhead, auf den ich mich bezog, war, weil ich dachte, dass dieser Aktualisierungsprozess automatisch durchgeführt wurde.
Eines der großartigen Dinge an JWT ist, dass Sie es nicht auf der Serverseite verfolgen müssen.Das heißt, sie sind flexibel und können auf viele verschiedene Arten verwendet werden. Es kommt also nur darauf an, was Sie daraus machen möchten.Das Szenario, die Lebensdauer eines Tokens begrenzen zu wollen, ohne ihn zu stören, weil er sich ständig neu anmelden muss, ist genau der Fall, in dem ein Token mit Ablauf und Aktualisierungsablauf gelöst wird.Es läuft nach 10 Minuten ab. Zu diesem Zeitpunkt muss die App eine explizite Anfrage an den Server senden, um zu sagen: "Kann ich ein anderes Token haben?"- an diesem Punkt könnte es nein sagen, weil sich die Dinge geändert haben.
#5
+3
Daniel Szpisjak
2019-02-19 11:47:44 UTC
view on stackexchange narkive permalink

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.

#6
+3
keithRozario
2019-03-19 18:03:48 UTC
view on stackexchange narkive permalink

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.

#7
+1
Krist Jin
2019-09-21 12:17:56 UTC
view on stackexchange narkive permalink

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.

Hallo!Eine gute Balance kann darin bestehen, kurzlebige JWT-Zugriffstoken und langlebige undurchsichtige (Nicht-JWT) Aktualisierungstoken zu haben.Wenn Sie eine Sperrliste benötigen, können Sie diese nur für das Aktualisierungstoken verwenden. Wenn Sie also Zugriffstoken verwenden, müssen Sie keine Datenbank-Suche durchführen (immer noch skalierbar).Wenn Sie jedoch das Aktualisierungstoken verwenden (nicht so häufig), können Sie diese Liste überprüfen.Weitere Informationen finden Sie auf [diesem Blog] (https://supertokens.io/blog/all-you-need-to-know-about-user-session-security)


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...