JSON-Web-Token ungültig machen

420

Für ein neues node.js-Projekt, an dem ich arbeite, denke ich darüber nach, von einem Cookie-basierten Sitzungsansatz zu wechseln (damit meine ich das Speichern einer ID in einem Schlüsselwertspeicher, der Benutzersitzungen im Browser eines Benutzers enthält). zu einem tokenbasierten Sitzungsansatz (kein Schlüsselwertspeicher) unter Verwendung von JSON-Web-Tokens (jwt).

Das Projekt ist ein Spiel, das socket.io verwendet. Eine tokenbasierte Sitzung wäre in einem solchen Szenario nützlich, in dem mehrere Kommunikationskanäle in einer einzigen Sitzung vorhanden sind (web und socket.io).

Wie würde man mit dem jwt-Ansatz eine Token- / Sitzungsinvalidierung vom Server bereitstellen?

Ich wollte auch verstehen, auf welche häufigen (oder ungewöhnlichen) Fallstricke / Angriffe ich bei dieser Art von Paradigma achten sollte. Zum Beispiel, wenn dieses Paradigma für dieselben / unterschiedliche Arten von Angriffen anfällig ist wie der auf Session Store / Cookies basierende Ansatz.

Sagen wir also, ich habe folgendes (angepasst von diesem und jenem ):

Session Store Login:

app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        // Create session token
        var token= createSessionToken();

        // Add to a key-value database
        KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});

        // The client should save this session token in a cookie
        response.json({sessionToken: token});
    });
}

Token-basiertes Login:

var jwt = require('jsonwebtoken');
app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60});
        response.json({token: token});
    });
}

- -

Eine Abmeldung (oder Ungültigmachung) für den Session Store-Ansatz würde eine Aktualisierung der KeyValueStore-Datenbank mit dem angegebenen Token erfordern.

Es scheint, als würde ein solcher Mechanismus im tokenbasierten Ansatz nicht existieren, da das Token selbst die Informationen enthalten würde, die normalerweise im Schlüsselwertspeicher vorhanden wären.

funseiki
quelle
1
Wenn Sie das Paket 'express-jwt' verwenden, können Sie sich die isRevokedOption ansehen oder versuchen, dieselbe Funktionalität zu replizieren. github.com/auth0/express-jwt#revoked-tokens
Signus
1
Verwenden Sie eine kurze Ablaufzeit für das Zugriffstoken und ein Aktualisierungstoken mit einem langlebigen Ablauf, um den Zugriffsstatus des Benutzers in einer Datenbank zu überprüfen (Blacklisting). auth0.com/blog/…
Rohmer
Eine andere Option wäre das Anhängen einer IP-Adresse an die Nutzdaten beim Generieren eines JWT-Tokens und das Überprüfen der gespeicherten IP-Adresse im Vergleich zur eingehenden Anforderung derselben IP-Adresse. Beispiel: req.connection.remoteAddress in nodeJs. Es gibt ISP-Anbieter, die keine statische IP pro Kunde ausgeben. Ich denke, dies ist kein Problem, es sei denn, ein Client stellt erneut eine Verbindung zum Internet her.
Gihan Sandaru

Antworten:

390

Auch ich habe diese Frage untersucht, und obwohl keine der folgenden Ideen vollständige Lösungen sind, können sie anderen helfen, Ideen auszuschließen oder weitere bereitzustellen.

1) Entfernen Sie einfach das Token vom Client

Dies hat natürlich nichts mit der serverseitigen Sicherheit zu tun, stoppt jedoch einen Angreifer, indem das Token aus der Existenz entfernt wird (dh, er müsste das Token vor dem Abmelden gestohlen haben).

2) Erstellen Sie eine Token-Blacklist

Sie können die ungültigen Token bis zu ihrem ursprünglichen Ablaufdatum speichern und mit eingehenden Anforderungen vergleichen. Dies scheint jedoch den Grund für die vollständige Token-basierte Verneinung zu negieren, da Sie die Datenbank für jede Anforderung berühren müssten. Die Speichergröße wäre jedoch wahrscheinlich geringer, da Sie nur Token speichern müssten, die zwischen Abmelde- und Ablaufzeit liegen (dies ist ein Bauchgefühl und hängt definitiv vom Kontext ab).

3) Halten Sie die Ablaufzeiten der Token einfach kurz und drehen Sie sie häufig

Wenn Sie die Ablaufzeiten des Tokens in ausreichend kurzen Intervallen einhalten und den laufenden Client bei Bedarf verfolgen und Aktualisierungen anfordern lassen, funktioniert Nummer 1 effektiv als vollständiges Abmeldesystem. Das Problem bei dieser Methode besteht darin, dass es unmöglich ist, den Benutzer zwischen dem Schließen des Client-Codes angemeldet zu halten (abhängig davon, wie lange Sie das Ablaufintervall einhalten).

Notfallpläne

Wenn jemals ein Notfall aufgetreten ist oder ein Benutzertoken kompromittiert wurde, können Sie dem Benutzer erlauben, eine zugrunde liegende Benutzersuch-ID mit ihren Anmeldeinformationen zu ändern. Dies würde alle zugeordneten Token ungültig machen, da der zugeordnete Benutzer nicht mehr gefunden werden kann.

Ich wollte auch darauf hinweisen, dass es eine gute Idee ist, das letzte Anmeldedatum in das Token aufzunehmen, damit Sie nach einiger Zeit eine erneute Anmeldung erzwingen können.

In Bezug auf Ähnlichkeiten / Unterschiede in Bezug auf Angriffe mit Token wird in diesem Beitrag die Frage behandelt: https://github.com/dentarg/blog/blob/master/_posts/2014-01-07-angularjs-authentication-with-cookies -vs-token.markdown

Matt Way
quelle
3
Hervorragender Ansatz. Mein Bauch wäre es, eine Kombination aller 3 zu machen und / oder nach jeder "n" -Anforderung ein neues Token anzufordern (im Gegensatz zu einem Timer). Wir verwenden Redis für die speicherinterne Objektspeicherung, und wir könnten dies leicht für Fall 2 verwenden, und dann würde die Latenz erheblich sinken.
Aaron Wagner
2
Dieser Coding-Horror-Beitrag bietet einige Ratschläge: Halten Sie sitzungstragende Cookies (oder Token) kurz, aber machen Sie sie für den Benutzer unsichtbar - was mit # 3 in Einklang zu stehen scheint. Mein eigener Bauch (vielleicht weil es traditioneller ist) ist nur, dass das Token (oder ein Hash davon) als Schlüssel für die Sitzungsdatenbank auf der weißen Liste fungiert (ähnlich wie # 2)
funseiki
7
Der Artikel ist gut geschrieben und eine ausgearbeitete Version von 2)oben. Obwohl es gut funktioniert, sehe ich persönlich keinen großen Unterschied zu herkömmlichen Session Stores. Ich denke, der Speicherbedarf wäre geringer, aber Sie benötigen immer noch eine Datenbank. Der größte Reiz von JWT war für mich, überhaupt keine Datenbank für Sitzungen zu verwenden.
Matt Way
208
Ein gängiger Ansatz zum Ungültigmachen von Token, wenn ein Benutzer sein Kennwort ändert, besteht darin, das Token mit einem Hash seines Kennworts zu signieren. Wenn sich das Kennwort ändert, können frühere Token automatisch nicht überprüft werden. Sie können dies auf die Abmeldung erweitern, indem Sie eine letzte Abmeldezeit in den Benutzerdatensatz aufnehmen und eine Kombination aus der letzten Abmeldezeit und dem Kennwort-Hash zum Signieren des Tokens verwenden. Dies erfordert jedes Mal eine DB-Suche, wenn Sie die Tokensignatur überprüfen müssen, aber vermutlich suchen Sie den Benutzer trotzdem.
Travis Terry
4
Eine Blacklist kann effizient gestaltet werden, indem sie im Speicher bleibt, sodass die Datenbank nur getroffen werden muss, um Ungültigmachungen aufzuzeichnen und abgelaufene Ungültigmachungen zu entfernen und nur beim Serverstart zu lesen. Bei einer Lastausgleichsarchitektur kann die speicherinterne Blacklist die Datenbank in kurzen Intervallen (z. B. 10 Sekunden) abfragen, wodurch die Gefährdung durch ungültige Token begrenzt wird. Mit diesen Ansätzen kann der Server weiterhin Anforderungen ohne DB-Zugriffe pro Anforderung authentifizieren.
Joe Lapp
85

Die oben genannten Ideen sind gut, aber eine sehr einfache und einfache Möglichkeit, alle vorhandenen JWTs ungültig zu machen, besteht darin, einfach das Geheimnis zu ändern.

Wenn Ihr Server das JWT erstellt, es mit einem Geheimnis (JWS) signiert und dann an den Client sendet, werden durch einfaches Ändern des Geheimnisses alle vorhandenen Token ungültig und alle Benutzer müssen ein neues Token zur Authentifizierung erhalten, da ihr altes Token plötzlich ungültig wird zum Server.

Es sind keine Änderungen am tatsächlichen Token-Inhalt (oder an der Lookup-ID) erforderlich.

Dies funktioniert natürlich nur in einem Notfall, in dem alle vorhandenen Token ablaufen sollen. Für das Ablaufen eines Tokens ist eine der oben genannten Lösungen erforderlich (z. B. kurze Ablaufzeit des Tokens oder Ungültigmachen eines im Token gespeicherten Schlüssels).

Andy
quelle
9
Ich denke, dieser Ansatz ist nicht ideal. Stellen Sie sich einen Fall vor, in dem Sie einen öffentlichen Schlüssel verwenden, obwohl dies funktioniert und sicherlich einfach ist. Sie möchten diesen Schlüssel nicht jedes Mal neu erstellen, wenn Sie ein einzelnes Token ungültig machen möchten.
Signus
1
@KijanaWoodard, ein öffentliches / privates Schlüsselpaar kann verwendet werden, um die Signatur als das Geheimnis des RS256-Algorithmus zu validieren. In dem hier gezeigten Beispiel erwähnt er, dass das Geheimnis geändert wird, um eine JWT ungültig zu machen. Dies kann entweder durch a) Einführen eines gefälschten Pubkeys, der nicht mit der Signatur übereinstimmt, oder b) Generieren eines neuen Pubkeys erfolgen. In dieser Situation ist es weniger als ideal.
Signus
1
@ Signus - Gotcha. Verwenden Sie den öffentlichen Schlüssel nicht als Geheimnis, aber andere verlassen sich möglicherweise auf den öffentlichen Schlüssel, um die Signatur zu überprüfen.
Kijana Woodard
8
Das ist eine sehr schlechte Lösung. Hauptgrund für die Verwendung von JWT ist, dass es zustandslos ist und skaliert. Die Verwendung eines dynamischen Geheimnisses führt einen Zustand ein. Wenn der Dienst über mehrere Knoten verteilt ist, müssen Sie das Geheimnis jedes Mal synchronisieren, wenn ein neues Token ausgegeben wird. Sie müssten Geheimnisse in einer Datenbank oder einem anderen externen Dienst speichern, der lediglich die Cookie-basierte Authentifizierung neu erfinden würde
Tuomas Toivonen
5
@ TuomasToivonen, aber Sie müssen eine JWT mit einem Geheimnis unterschreiben und in der Lage sein, die JWT mit demselben Geheimnis zu verifizieren. Sie müssen das Geheimnis also in den geschützten Ressourcen speichern. Wenn das Geheimnis gefährdet ist, müssen Sie es ändern und diese Änderung an jeden Ihrer Knoten verteilen. Hosting-Anbieter mit Clustering / Skalierung ermöglichen es Ihnen normalerweise, Geheimnisse in ihrem Dienst zu speichern, um die Verteilung dieser Geheimnisse einfach und zuverlässig zu gestalten.
Rohmer
66

Dies ist in erster Linie ein langer Kommentar, der die Antwort von @mattway unterstützt und darauf aufbaut

Gegeben:

Einige der anderen auf dieser Seite vorgeschlagenen Lösungen empfehlen, bei jeder Anforderung den Datenspeicher aufzurufen. Wenn Sie den Hauptdatenspeicher aufrufen, um jede Authentifizierungsanforderung zu validieren, sehe ich weniger Gründe, JWT anstelle anderer etablierter Token-Authentifizierungsmechanismen zu verwenden. Sie haben JWT im Wesentlichen statusbehaftet und nicht zustandslos gemacht, wenn Sie jedes Mal zum Datenspeicher gehen.

(Wenn Ihre Site eine große Anzahl nicht autorisierter Anfragen erhält, würde JWT diese ablehnen, ohne den Datenspeicher zu erreichen, was hilfreich ist. Es gibt wahrscheinlich andere Anwendungsfälle wie diesen.)

Gegeben:

Eine wirklich zustandslose JWT-Authentifizierung kann für eine typische reale Web-App nicht erreicht werden, da zustandslose JWT keine Möglichkeit bietet, sofortige und sichere Unterstützung für die folgenden wichtigen Anwendungsfälle bereitzustellen :

Das Benutzerkonto wird gelöscht / gesperrt / gesperrt.

Das Passwort des Benutzers wird geändert.

Die Rollen oder Berechtigungen des Benutzers werden geändert.

Der Benutzer wird vom Administrator abgemeldet.

Alle anderen anwendungskritischen Daten im JWT-Token werden vom Site-Administrator geändert.

In diesen Fällen können Sie nicht auf den Ablauf des Tokens warten. Die Token-Ungültigmachung muss sofort erfolgen. Sie können dem Client auch nicht vertrauen, dass er keine Kopie des alten Tokens aufbewahrt und verwendet, sei es mit böswilliger Absicht oder nicht.

Deshalb: Ich denke, die Antwort von @ matt-way, # 2 TokenBlackList, wäre die effizienteste Möglichkeit, der JWT-basierten Authentifizierung den erforderlichen Status hinzuzufügen.

Sie haben eine schwarze Liste, die diese Token enthält, bis ihr Ablaufdatum erreicht ist. Die Liste der Token ist im Vergleich zur Gesamtzahl der Benutzer recht klein, da nur Token auf der schwarzen Liste bis zu ihrem Ablauf aufbewahrt werden müssen. Ich würde implementieren, indem ungültige Token in Redis, Memcached oder einem anderen speicherinternen Datenspeicher abgelegt werden, der das Festlegen einer Ablaufzeit für einen Schlüssel unterstützt.

Sie müssen weiterhin für jede Authentifizierungsanforderung, die die anfängliche JWT-Authentifizierung besteht, einen Anruf bei Ihrer In-Memory-Datenbank tätigen, müssen jedoch nicht die Schlüssel für Ihre gesamte Benutzergruppe darin speichern. (Was für eine bestimmte Site eine große Sache sein kann oder nicht.)

Ed J.
quelle
15
Ich stimme Ihrer Antwort nicht zu. Wenn Sie auf eine Datenbank zugreifen, wird nichts aussagekräftig. Das Speichern des Status in Ihrem Backend funktioniert. JWT wurde nicht erstellt, damit Sie nicht bei jeder Anforderung auf die Datenbank zugreifen müssen. Jede wichtige Anwendung, die JWT verwendet, wird von einer Datenbank unterstützt. JWT löst ein völlig anderes Problem. en.wikipedia.org/wiki/Stateless_protocol
Julian
6
@Julian kannst du das etwas näher erläutern? Welches Problem löst JWT dann wirklich?
zero01alpha
8
@ zero01alpha Authentifizierung: Dies ist das häufigste Szenario für die Verwendung von JWT. Sobald der Benutzer angemeldet ist, enthält jede nachfolgende Anforderung die JWT, sodass der Benutzer auf Routen, Dienste und Ressourcen zugreifen kann, die mit diesem Token zulässig sind. Informationsaustausch: JSON-Web-Token sind eine gute Möglichkeit, Informationen sicher zwischen Parteien zu übertragen. Da JWTs signiert werden können, können Sie sicher sein, dass die Absender so sind, wie sie sagen. Siehe jwt.io/introduction
Julian
7
@Julian Ich bin mit Ihrer Meinungsverschiedenheit nicht einverstanden :) JWT löst das Problem (für Dienste), dass auf eine zentralisierte Stelle zugegriffen werden muss, die Autorisierungsinformationen für einen bestimmten Kunden bereitstellt. Anstatt dass Service A und Service B auf eine Ressource zugreifen müssen, um herauszufinden, ob Client X über Berechtigungen verfügt oder nicht, erhalten Service A und B von X ein Token, das seine Berechtigungen bestätigt (am häufigsten von einem Dritten ausgestellt) Party). Auf jeden Fall ist JWT ein Tool, mit dem ein gemeinsamer Status zwischen Diensten in einem System vermieden werden kann, insbesondere wenn diese von mehr als einem Dienstanbieter gesteuert werden.
Livanov
1
Auch von jwt.io/introduction If the JWT contains the necessary data, the need to query the database for certain operations may be reduced, though this may not always be the case.
Giantas
43

Ich würde die jwt-Versionsnummer auf dem Benutzermodell aufzeichnen. Neue JWT-Token würden ihre Version darauf einstellen.

Wenn Sie das JWT validieren, überprüfen Sie einfach, ob es eine Versionsnummer hat, die der aktuellen JWT-Version des Benutzers entspricht.

Jedes Mal, wenn Sie alte JWTS ungültig machen möchten, geben Sie einfach die JWT-Versionsnummer des Benutzers an.

DaftMonk
quelle
15
Dies ist eine interessante Idee. Die einzige Sache ist, wo die Version gespeichert werden soll. Als Teil des Zwecks von Token ist es, dass sie zustandslos sind und die Datenbank nicht verwenden müssen. Eine fest codierte Version würde das Stoßen erschweren, und eine Versionsnummer in einer Datenbank würde einige der Vorteile der Verwendung von Token zunichte machen.
Stephen Smith
13
Vermutlich speichern Sie bereits eine Benutzer-ID in Ihrem Token und fragen dann die Datenbank ab, um zu überprüfen, ob der Benutzer vorhanden ist / zum Zugriff auf den API-Endpunkt berechtigt ist. Sie führen also keine zusätzlichen Datenbankabfragen durch, indem Sie die Versionsnummer des JWT-Tokens mit der des Benutzers vergleichen.
DaftMonk
5
Ich sollte es vermutlich nicht sagen, da es viele Situationen gibt, in denen Sie Token mit Validierungen verwenden könnten, die die Datenbank überhaupt nicht berühren. Aber ich denke in diesem Fall ist es schwer zu vermeiden.
DaftMonk
11
Was passiert, wenn sich der Benutzer von mehreren Geräten aus anmeldet? Sollte ein Token für alle verwendet werden oder sollte die Anmeldung alle vorherigen ungültig machen?
MeeDamian
10
Ich stimme @SergioCorrea zu. Dies würde JWT fast so aussagekräftig machen wie jeden anderen Token-Authentifizierungsmechanismus.
Ed J
40

Ich habe dies noch nicht versucht und es werden viele Informationen verwendet, die auf einigen der anderen Antworten basieren. Die Komplexität besteht darin, einen serverseitigen Datenspeicheraufruf pro Anforderung von Benutzerinformationen zu vermeiden. Die meisten anderen Lösungen erfordern eine Datenbank-Suche pro Anforderung an einen Benutzersitzungsspeicher. Das ist in bestimmten Szenarien in Ordnung, wurde jedoch erstellt, um solche Aufrufe zu vermeiden und den erforderlichen serverseitigen Status sehr klein zu halten. Am Ende wird eine serverseitige Sitzung neu erstellt, die jedoch klein ist, um alle Funktionen zur erzwungenen Ungültigmachung bereitzustellen. Aber wenn Sie es hier tun möchten, ist das Wesentliche:

Tore:

  • Reduzieren Sie die Verwendung eines Datenspeichers (ohne Status).
  • Möglichkeit, das Abmelden aller Benutzer zu erzwingen.
  • Möglichkeit, das Abmelden einer Person jederzeit zu erzwingen.
  • Möglichkeit, nach einer bestimmten Zeit eine erneute Eingabe des Passworts zu verlangen.
  • Möglichkeit, mit mehreren Clients zu arbeiten.
  • Möglichkeit, eine erneute Anmeldung zu erzwingen, wenn ein Benutzer von einem bestimmten Client auf Abmelden klickt. (Um zu verhindern, dass jemand ein Client-Token "löscht", nachdem der Benutzer weggegangen ist - weitere Informationen finden Sie in den Kommentaren.)

Die Lösung:

  • Verwenden Sie kurzlebige (<5 m) Zugriffstoken, die mit einem längerlebigen (einige Stunden) Client- Aktualisierungstoken gepaart sind .
  • Jede Anforderung überprüft entweder das Ablaufdatum des Authentifizierungs- oder Aktualisierungstokens auf Gültigkeit.
  • Wenn das Zugriffstoken abläuft, verwendet der Client das Aktualisierungstoken, um das Zugriffstoken zu aktualisieren.
  • Während der Überprüfung des Aktualisierungstokens überprüft der Server eine kleine schwarze Liste von Benutzer-IDs. Wenn diese gefunden werden, lehnen Sie die Aktualisierungsanforderung ab.
  • Wenn ein Client kein gültiges (nicht abgelaufenes) Aktualisierungs- oder Authentifizierungstoken hat, muss sich der Benutzer erneut anmelden, da alle anderen Anforderungen abgelehnt werden.
  • Überprüfen Sie bei Anmeldeanforderung den Benutzerdatenspeicher auf Verbot.
  • Beim Abmelden - Fügen Sie diesen Benutzer zur Sitzungs-Blacklist hinzu, damit er sich erneut anmelden muss. Sie müssten zusätzliche Informationen speichern, um sie nicht von allen Geräten in einer Umgebung mit mehreren Geräten abzumelden. Dies kann jedoch durch Hinzufügen eines Gerätefelds zum Feld erfolgen Benutzer Blacklist.
  • Um die erneute Eingabe nach x Zeit zu erzwingen, behalten Sie das letzte Anmeldedatum im Authentifizierungstoken bei und überprüfen Sie es pro Anforderung.
  • Um das Abmelden aller Benutzer zu erzwingen, setzen Sie den Token-Hash-Schlüssel zurück.

Dies erfordert, dass Sie eine Blacklist (Status) auf dem Server verwalten, vorausgesetzt, die Benutzertabelle enthält gesperrte Benutzerinformationen. Die Blacklist für ungültige Sitzungen - ist eine Liste der Benutzer-IDs. Diese schwarze Liste wird nur während einer Aktualisierungstokenanforderung überprüft. Einträge sind erforderlich, um darauf zu leben, solange das Aktualisierungstoken TTL. Nach Ablauf des Aktualisierungstokens muss sich der Benutzer erneut anmelden.

Nachteile:

  • Es ist weiterhin erforderlich, eine Datenspeichersuche für die Aktualisierungstokenanforderung durchzuführen.
  • Für die TTL des Zugriffstokens werden möglicherweise weiterhin ungültige Token verwendet.

Vorteile:

  • Bietet die gewünschte Funktionalität.
  • Die Aktion zum Aktualisieren des Tokens ist dem Benutzer im normalen Betrieb verborgen.
  • Anstelle jeder Anforderung muss nur eine Datenspeichersuche für Aktualisierungsanforderungen durchgeführt werden. dh 1 alle 15 Minuten statt 1 pro Sekunde.
  • Minimiert den serverseitigen Status auf eine sehr kleine schwarze Liste.

Mit dieser Lösung wird kein In-Memory-Datenspeicher wie reddis benötigt, zumindest nicht für Benutzerinformationen, da der Server nur etwa alle 15 Minuten einen Datenbankaufruf tätigt. Wenn Sie reddis verwenden, ist das Speichern einer gültigen / ungültigen Sitzungsliste eine sehr schnelle und einfachere Lösung. Kein Aktualisierungstoken erforderlich. Jedes Authentifizierungstoken hätte eine Sitzungs-ID und eine Geräte-ID. Sie könnten bei der Erstellung in einer reddis-Tabelle gespeichert und gegebenenfalls ungültig gemacht werden. Dann würden sie bei jeder Anfrage überprüft und bei Ungültigkeit abgelehnt.

Ashtonian
quelle
Was ist mit dem Szenario, in dem eine Person von einem Computer aufsteht, damit eine andere Person denselben Computer verwendet? Die 1. Person meldet sich ab und erwartet, dass die Abmeldung die 2. Person sofort blockiert. Wenn die 2. Person ein durchschnittlicher Benutzer ist, kann der Client den Benutzer leicht blockieren, indem er das Token löscht. Wenn der 2. Benutzer jedoch über Hacking-Kenntnisse verfügt, hat der Benutzer Zeit, das noch gültige Token wiederherzustellen, um sich als 1. Benutzer zu authentifizieren. Es scheint nicht zu vermeiden, dass Token unverzüglich sofort ungültig gemacht werden müssen.
Joe Lapp
5
Oder Sie können Ihr JWT aus der Sitzung / dem lokalen Speicher oder dem Cookie entfernen.
Kamil Kiełczewski
1
Danke @Ashtonian. Nach umfangreichen Recherchen habe ich JWTs aufgegeben. JWTs sind viel anfälliger als reguläre Sitzungen, es sei denn, Sie unternehmen außerordentliche Anstrengungen, um den geheimen Schlüssel zu sichern, oder Sie delegieren an eine sichere OAuth-Implementierung. Siehe meinen vollständigen Bericht: by.jtl.xyz/2016/06/the-unspoken-vulnerability-of-jwts.html
Joe Lapp
2
Die Verwendung eines Aktualisierungstokens ist der Schlüssel zum Zulassen einer schwarzen Liste. Tolle Erklärung: auth0.com/blog/…
Rohmer
1
Dies scheint mir die beste Antwort zu sein, da es ein kurzlebiges Zugriffstoken mit einem langlebigen Aktualisierungstoken kombiniert, das auf die schwarze Liste gesetzt werden kann. Beim Abmelden sollte der Client das Zugriffstoken löschen, damit ein zweiter Benutzer keinen Zugriff erhält (obwohl das Zugriffstoken nach dem Abmelden noch einige Minuten gültig bleibt). @ Joe Lapp sagt, dass ein Hacker (2. Benutzer) das Zugriffstoken auch nach dem Löschen erhält. Wie?
M3RS
14

Ein Ansatz, über den ich nachgedacht habe, besteht darin, immer einen iat(ausgegebenen) Wert in der JWT zu haben. Wenn sich ein Benutzer abmeldet, speichern Sie diesen Zeitstempel im Benutzerdatensatz. Vergleichen Sie bei der Validierung des JWT einfach iatden zuletzt abgemeldeten Zeitstempel. Wenn das iatälter ist, ist es nicht gültig. Ja, Sie müssen zur Datenbank gehen, aber ich werde trotzdem immer den Benutzerdatensatz abrufen, wenn die JWT ansonsten gültig ist.

Der größte Nachteil, den ich sehe, ist, dass sie von allen Sitzungen abgemeldet werden, wenn sie sich in mehreren Browsern befinden oder auch einen mobilen Client haben.

Dies könnte auch ein guter Mechanismus sein, um alle JWTs in einem System ungültig zu machen. Ein Teil der Prüfung könnte gegen einen globalen Zeitstempel der letzten gültigen iatZeit erfolgen.

Brack Mo.
quelle
1
Guter Gedanke! Um das Problem "Ein Gerät" zu lösen, muss dies eher eine Notfallfunktion als eine Abmeldung sein. Speichern Sie das Datum a im Benutzerdatensatz, das alle zuvor ausgegebenen Token ungültig macht. So etwas token_valid_afteroder so. Genial!
OneHoopyFrood
1
Hey @OneHoopyFrood Sie haben einen Beispielcode, der mir hilft, die Idee besser zu verstehen? Ich schätze deine Hilfe sehr!
Alexventuraio
2
Wie alle anderen vorgeschlagenen Lösungen erfordert auch diese eine Datenbanksuche, weshalb diese Frage besteht, da das Vermeiden dieser Suche hier das Wichtigste ist! (Leistung, Skalierbarkeit). Unter normalen Umständen benötigen Sie keine DB-Suche, um die Benutzerdaten zu erhalten. Sie haben sie bereits vom Client erhalten.
Rob Evans
9

Ich bin hier etwas spät dran, aber ich denke, ich habe eine anständige Lösung.

Ich habe eine Spalte "last_password_change" in meiner Datenbank, in der Datum und Uhrzeit der letzten Änderung des Kennworts gespeichert sind. Ich speichere auch das Datum / die Uhrzeit der Ausgabe im JWT. Bei der Validierung eines Tokens überprüfe ich, ob das Kennwort nach der Ausgabe des Tokens geändert wurde und ob das Token abgelehnt wurde, obwohl es noch nicht abgelaufen ist.

Matas Kairaitis
quelle
1
Wie lehnen Sie den Token ab? Können Sie einen kurzen Beispielcode zeigen?
Alexventuraio
1
if (jwt.issue_date < user.last_pw_change) { /* not valid, redirect to login */}
Vanuan
15
Benötigt eine Datenbank-Suche!
Rob Evans
5

Sie können ein "last_key_used" -Feld in Ihrer Datenbank im Dokument / Datensatz Ihres Benutzers haben.

Wenn sich der Benutzer mit Benutzer anmeldet und übergibt, generieren Sie eine neue zufällige Zeichenfolge, speichern Sie sie im Feld last_key_used und fügen Sie sie beim Signieren des Tokens zur Nutzlast hinzu.

Wenn sich der Benutzer mit dem Token anmeldet, überprüfen Sie, ob der in der Datenbank verwendete last_key_key mit dem im Token übereinstimmt.

Wenn der Benutzer beispielsweise eine Abmeldung vornimmt oder wenn Sie das Token ungültig machen möchten, ändern Sie einfach das Feld "last_key_used" in einen anderen zufälligen Wert. Alle nachfolgenden Überprüfungen schlagen fehl, sodass der Benutzer sich mit dem Benutzer anmelden und erneut übergeben muss.

NickVarcha
quelle
Dies ist die Lösung, über die ich nachgedacht habe, die jedoch folgende Nachteile aufweist: (1) Sie führen entweder bei jeder Anforderung eine DB-Suche durch, um den Zufall zu überprüfen (wodurch der Grund für die Verwendung von Token anstelle von Sitzungen aufgehoben wird), oder Sie sind es nur zeitweise nach Ablauf eines Aktualisierungstokens überprüfen (verhindern, dass sich Benutzer sofort abmelden oder Sitzungen sofort beendet werden); und (2) Abmelden meldet den Benutzer von allen Browsern und allen Geräten ab (was herkömmlicherweise nicht erwartet wird).
Joe Lapp
Sie müssen den Schlüssel nicht ändern, wenn sich der Benutzer abmeldet, sondern nur, wenn er sein Kennwort ändert oder - wenn Sie es angeben - wenn er sich von allen Geräten
abmeldet
3

Führen Sie eine solche In-Memory-Liste

user_id   revoke_tokens_issued_before
-------------------------------------
123       2018-07-02T15:55:33
567       2018-07-01T12:34:21

Wenn Ihre Token in einer Woche ablaufen, bereinigen oder ignorieren Sie die älteren Datensätze. Bewahren Sie außerdem nur die neuesten Aufzeichnungen jedes Benutzers auf. Die Größe der Liste hängt davon ab, wie lange Sie Ihre Token aufbewahren und wie oft Benutzer ihre Token widerrufen. Verwenden Sie db nur, wenn sich die Tabelle ändert. Laden Sie die Tabelle in den Speicher, wenn Ihre Anwendung gestartet wird.

Eduardo
quelle
2
Die meisten Produktionsstandorte werden auf mehr als einem Server ausgeführt, sodass diese Lösung nicht funktioniert. Das Hinzufügen von Redis oder einem ähnlichen Interpocess-Cache verkompliziert das System erheblich und bringt häufig mehr Probleme als Lösungen mit sich.
user2555515
@ user2555515 Alle Server können mit der Datenbank synchronisiert werden. Sie haben die Wahl, jedes Mal auf die Datenbank zuzugreifen oder nicht. Man konnte sehen, welche Probleme es bringt.
Eduardo
3

------------------------ Etwas spät für diese Antwort, aber es kann sein, dass es jemandem hilft ------------- -----------

Auf der Clientseite ist es am einfachsten, das Token aus dem Speicher des Browsers zu entfernen.

Was ist, wenn Sie das Token auf dem Knotenserver zerstören möchten?

Das Problem mit dem JWT-Paket ist, dass es keine Methode oder Möglichkeit zum Zerstören des Tokens bietet. Sie können in Bezug auf JWT verschiedene Methoden verwenden, die oben erwähnt wurden. Aber hier gehe ich mit den JWT-Redis.

Um das Token auf der Serverseite zu zerstören, können Sie anstelle von JWT das Paket jwt-redis verwenden

Diese Bibliothek (jwt-redis) wiederholt die gesamte Funktionalität der Bibliothek jsonwebtoken mit einer wichtigen Ergänzung vollständig. Mit Jwt-redis können Sie das Token-Label in redis speichern, um die Gültigkeit zu überprüfen. Das Fehlen eines Token-Labels in redis macht das Token ungültig. Um das Token in jwt-redis zu zerstören, gibt es eine Zerstörungsmethode

es funktioniert so:

1) Installieren Sie jwt-redis von npm

2) Erstellen -

var redis = require('redis');
var JWTR =  require('jwt-redis').default;
var redisClient = redis.createClient();
var jwtr = new JWTR(redisClient);

jwtr.sign(payload, secret)
    .then((token)=>{
            // your code
    })
    .catch((error)=>{
            // error handling
    });

3) Zur Überprüfung -

jwtr.verify(token, secret);

4) Zu zerstören -

jwtr.destroy(token)

Hinweis : Sie können expiresIn während der Anmeldung des Tokens auf dieselbe Weise wie in JWT bereitstellen.

Vielleicht hilft das jemandem

Aman Kumar Gupta
quelle
2

Warum nicht einfach den jti-Claim (nonce) verwenden und diesen in einer Liste als Benutzerdatensatzfeld speichern (db-abhängig, aber zumindest eine durch Kommas getrennte Liste ist in Ordnung)? Es ist keine separate Suche erforderlich, da andere darauf hingewiesen haben, dass Sie den Benutzerdatensatz vermutlich trotzdem erhalten möchten. Auf diese Weise können Sie mehrere gültige Token für verschiedene Clientinstanzen haben ("Überall abmelden" kann die Liste auf leer zurücksetzen).

Davidkomer
quelle
Ja das. Stellen Sie möglicherweise eine Eins-zu-Viele-Beziehung zwischen der Benutzertabelle und einer neuen (Sitzungs-) Tabelle her, damit Sie Metadaten zusammen mit den jti-Ansprüchen speichern können.
Peter Lada
2
  1. Geben Sie 1 Tag Ablaufzeit für die Token
  2. Führen Sie eine tägliche schwarze Liste.
  3. Fügen Sie die ungültig gemachten / abgemeldeten Token in die schwarze Liste ein

Überprüfen Sie für die Token-Validierung zuerst die Ablaufzeit des Tokens und dann die Blacklist, wenn das Token nicht abgelaufen ist.

Für lange Sitzungsanforderungen sollte es einen Mechanismus zum Verlängern der Token-Ablaufzeit geben.

Ebru Yener
quelle
4
Setzen Sie
2

Spät zur Party werden nach einigen Recherchen MEINE zwei Cent unten angegeben. Stellen Sie beim Abmelden sicher, dass folgende Dinge geschehen ...

Löschen Sie den Client-Speicher / die Client-Sitzung

Aktualisieren Sie die Benutzertabelle beim letzten Anmeldedatum und beim letzten Abmeldedatum, wenn die Anmeldung bzw. Abmeldung erfolgt. Die Uhrzeit des Anmeldedatums sollte daher immer größer als die Abmeldedate sein (oder das Abmeldedatum auf Null belassen, wenn der aktuelle Status "Anmelden" und noch nicht abgemeldet ist).

Dies ist weitaus einfacher, als eine zusätzliche schwarze Liste zu führen und regelmäßig zu löschen. Für die Unterstützung mehrerer Geräte ist eine zusätzliche Tabelle erforderlich, um angemeldet zu bleiben. Abmeldedaten mit einigen zusätzlichen Details wie Betriebssystem- oder Clientdetails.

Schamseer
quelle
2

Einzigartig pro Benutzerzeichenfolge und globaler String, der zusammen gehasht wurde

Um als geheimer JWT-Teil zu dienen, können sowohl einzelne als auch globale Token ungültig gemacht werden. Maximale Flexibilität auf Kosten einer Datenbank-Suche / -Lesung während der Anforderungsauthentifizierung. Auch einfach zwischenzuspeichern, da sie sich selten ändern.

Hier ist ein Beispiel:

HEADER:ALGORITHM & TOKEN TYPE

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

{
  "sub": "1234567890",
  "some": "data",
  "iat": 1516239022
}
VERIFY SIGNATURE

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload), 
  HMACSHA256('perUserString'+'globalString')
)

where HMACSHA256 is your local crypto sha256
  nodejs 
    import sha256 from 'crypto-js/sha256';
    sha256(message);

Beispiel: Verwendung siehe https://jwt.io (nicht sicher, ob sie mit dynamischen 256-Bit-Geheimnissen umgehen)

Mark Essel
quelle
1
Etwas mehr Details würden ausreichen
Riesen
2
@giantas, ich denke, was Mark meint, ist der Signaturteil. Verwenden Sie stattdessen nur einen einzigen Schlüssel zum Signieren des JWT und kombinieren Sie ihn mit einem Schlüssel, der für jeden Client eindeutig ist. Wenn Sie also die gesamte Sitzung eines Benutzers ungültig machen möchten, ändern Sie einfach den Schlüssel für diesen Benutzer. Wenn Sie die gesamte Sitzung in Ihrem System ungültig machen möchten, ändern Sie einfach diesen globalen Einzelschlüssel.
Tommy Aria Pradana
1

Ich habe es folgendermaßen gemacht:

  1. Generieren Sie ein unique hashund speichern Sie es in redis und Ihrem JWT . Dies kann als Sitzung bezeichnet werden
    • Wir speichern auch die Anzahl der Anforderungen, die der jeweilige JWT gestellt hat. Jedes Mal, wenn ein JWT an den Server gesendet wird, erhöhen wir die Ganzzahl der Anforderungen . (Dies ist optional)

Wenn sich ein Benutzer anmeldet, wird ein eindeutiger Hash erstellt, in redis gespeichert und in Ihr JWT eingefügt .

Wenn ein Benutzer versucht, einen geschützten Endpunkt zu besuchen, greifen Sie auf den eindeutigen Sitzungs-Hash von Ihrem JWT zu , fragen Redis ab und prüfen , ob er übereinstimmt!

Wir können daraus erweitern und unser JWT noch sicherer machen. So geht's:

Bei jeder X- Anforderung, die eine bestimmte JWT gestellt hat, generieren wir eine neue eindeutige Sitzung, speichern sie in unserer JWT und setzen die vorherige auf die schwarze Liste.

Dies bedeutet, dass sich die JWT ständig ändert und verhindert, dass abgestandene JWT gehackt, gestohlen oder etwas anderes wird.

James111
quelle
1
Sie können das Token selbst hashen und diesen Wert in redis speichern, anstatt einen neuen Hash in das Token einzufügen.
Frug
Überprüfen Sie auch audund jtibehauptet in JWT, Sie sind auf dem richtigen Weg.
Peter Lada
1

Wenn Sie Benutzertoken widerrufen möchten, können Sie alle ausgegebenen Token in Ihrer Datenbank verfolgen und prüfen, ob sie in einer sitzungsähnlichen Tabelle gültig (vorhanden) sind. Der Nachteil ist, dass Sie die DB bei jeder Anfrage treffen.

Ich habe es nicht ausprobiert, aber ich schlage die folgende Methode vor, um die Token-Sperrung zu ermöglichen und gleichzeitig die DB-Treffer auf ein Minimum zu beschränken:

Um die Datenbankprüfrate zu senken, teilen Sie alle ausgegebenen JWT-Token gemäß einer deterministischen Zuordnung (z. B. 10 Gruppen nach der ersten Ziffer der Benutzer-ID) in X-Gruppen auf.

Jedes JWT-Token enthält die Gruppen-ID und einen Zeitstempel, der bei der Token-Erstellung erstellt wurde. z.B,{ "group_id": 1, "timestamp": 1551861473716 }

Der Server speichert alle Gruppen-IDs im Speicher und jede Gruppe verfügt über einen Zeitstempel, der angibt, wann das letzte Abmeldeereignis eines Benutzers war, der zu dieser Gruppe gehört. z.B,{ "group1": 1551861473714, "group2": 1551861487293, ... }

Anforderungen mit einem JWT-Token mit einem älteren Gruppenzeitstempel werden auf Gültigkeit überprüft (DB-Treffer). Wenn sie gültig sind, wird ein neues JWT-Token mit einem neuen Zeitstempel für die zukünftige Verwendung durch den Client ausgegeben. Wenn der Gruppenzeitstempel des Tokens neuer ist, vertrauen wir dem JWT (kein DB-Treffer).

Damit -

  1. Wir validieren ein JWT-Token nur mithilfe der Datenbank, wenn das Token einen alten Gruppenzeitstempel hat, während zukünftige Anforderungen erst validiert werden, wenn sich jemand in der Benutzergruppe abmeldet.
  2. Wir verwenden Gruppen, um die Anzahl der Zeitstempeländerungen zu begrenzen (sagen wir, ein Benutzer meldet sich an und ab, als gäbe es kein Morgen - wirkt sich nur auf eine begrenzte Anzahl von Benutzern aus, anstatt auf alle).
  3. Wir begrenzen die Anzahl der Gruppen, um die Anzahl der im Speicher gespeicherten Zeitstempel zu begrenzen
  4. Das Ungültigmachen eines Tokens ist ein Kinderspiel. Entfernen Sie es einfach aus der Sitzungstabelle und generieren Sie einen neuen Zeitstempel für die Benutzergruppe.
Arik
quelle
Dieselbe Liste kann im Speicher gespeichert werden (Anwendung für c #) und es würde die Notwendigkeit beseitigen, die Datenbank für jede Anforderung zu treffen. Die Liste kann von db beim Start der Anwendung geladen werden
dvdmn
1

Wenn die Option "Von allen Geräten abmelden" akzeptabel ist (in den meisten Fällen):

  • Fügen Sie das Feld Token-Version zum Benutzerdatensatz hinzu.
  • Fügen Sie den Wert in diesem Feld zu den im JWT gespeicherten Ansprüchen hinzu.
  • Erhöhen Sie die Version jedes Mal, wenn sich der Benutzer abmeldet.
  • Vergleichen Sie bei der Validierung des Tokens seinen Versionsanspruch mit der im Benutzerdatensatz gespeicherten Version und lehnen Sie ihn ab, wenn er nicht identisch ist.

In den meisten Fällen ist ohnehin eine Datenbankauslösung erforderlich, um den Benutzerdatensatz abzurufen, sodass der Validierungsprozess nicht viel Aufwand verursacht. Im Gegensatz zur Verwaltung einer Blacklist, bei der die DB-Last aufgrund der Notwendigkeit, einen Join oder einen separaten Aufruf zu verwenden, erheblich ist, bereinigen Sie alte Datensätze usw.

user2555515
quelle
0

Ich werde antworten, wenn wir bei Verwendung von JWT eine Abmeldung von allen Gerätefunktionen bereitstellen müssen. Bei diesem Ansatz werden für jede Anforderung Datenbanksuchen verwendet. Weil wir einen Persistenzsicherheitsstatus benötigen, selbst wenn es zu einem Serverabsturz kommt. In der Benutzertabelle haben wir zwei Spalten

  1. LastValidTime (Standard: Erstellungszeit)
  2. Eingeloggt (Standard: true)

Immer wenn der Benutzer eine Abmeldeanforderung erhält, aktualisieren wir LastValidTime auf die aktuelle Zeit und Logged In auf false. Wenn eine Anmeldeanforderung vorliegt, ändern wir LastValidTime nicht, aber Logged-In wird auf true gesetzt.

Wenn wir das JWT erstellen, haben wir die JWT-Erstellungszeit in der Nutzlast. Wenn wir einen Service autorisieren, überprüfen wir 3 Bedingungen

  1. Ist JWT gültig?
  2. Ist die Erstellungszeit für JWT-Nutzdaten größer als die von User LastValidTime?
  3. Ist der Benutzer angemeldet?

Sehen wir uns ein praktisches Szenario an.

Benutzer X hat zwei Geräte A, B. Er hat sich um 19 Uhr mit Gerät A und Gerät B bei unserem Server angemeldet (sagen wir, die JWT-Ablaufzeit beträgt 12 Stunden). A und B haben beide JWT mit createdTime: 7pm

Um 21 Uhr verlor er sein Gerät B. Er meldet sich sofort von Gerät A ab. Das bedeutet, dass unser Benutzereintrag in Datenbank X jetzt LastValidTime als "ThatDate: 9: 00: xx: xxx" und als "false" angemeldet hat.

Um 9:30 Uhr versucht Mr.Thief, sich mit Gerät B anzumelden. Wir überprüfen die Datenbank, auch wenn die Anmeldung falsch ist, sodass wir dies nicht zulassen.

Um 22 Uhr meldet sich Mr.X von seinem Gerät A aus an. Jetzt hat Gerät A JWT mit der erstellten Zeit: 22 Uhr. Jetzt ist die angemeldete Datenbank auf "true" gesetzt.

Um 22:30 Uhr versucht Mr.Thief, sich anzumelden. Obwohl das Angemeldete wahr ist. Die LastValidTime ist 21 Uhr in der Datenbank, aber B's JWT hat die Zeit als 19 Uhr erstellt. Er darf also nicht auf den Dienst zugreifen. Wenn er also Gerät B ohne Kennwort verwendet, kann er das bereits erstellte JWT nicht verwenden, nachdem sich ein Gerät abgemeldet hat.

Tharsanan
quelle
0

IAM-Lösungen wie Keycloak (an denen ich gearbeitet habe) bieten Token Revocation-Endpunkte wie

Token-Sperrendpunkt /realms/{realm-name}/protocol/openid-connect/revoke

Wenn Sie einfach einen Benutzeragenten (oder Benutzer) abmelden möchten, können Sie auch einen Endpunkt aufrufen (dies würde die Token einfach ungültig machen). Auch im Fall von Keycloak muss die vertrauende Partei nur den Endpunkt anrufen

/realms/{realm-name}/protocol/openid-connect/logout

Link für den Fall, dass Sie mehr erfahren möchten

Subbu Mahadevan
quelle
-1

Dies scheint wirklich schwer zu lösen zu sein, ohne dass bei jeder Token-Überprüfung eine DB-Suche durchgeführt wird. Die Alternative, die ich mir vorstellen kann, besteht darin, eine schwarze Liste ungültiger Token auf der Serverseite zu führen. Dies sollte in einer Datenbank aktualisiert werden, wenn eine Änderung die Änderungen über Neustarts hinweg beibehält, indem der Server die Datenbank beim Neustart überprüft, um die aktuelle Blacklist zu laden.

Wenn Sie es jedoch im Serverspeicher behalten (eine Art globale Variable), kann es nicht auf mehrere Server skaliert werden, wenn Sie mehr als einen verwenden. In diesem Fall können Sie es also in einem gemeinsam genutzten Redis-Cache aufbewahren Einrichtung, um die Daten irgendwo zu speichern (Datenbank? Dateisystem?), falls sie neu gestartet werden müssen, und jedes Mal, wenn ein neuer Server hochgefahren wird, muss er den Redis-Cache abonnieren.

Alternativ zu einer schwarzen Liste können Sie mit derselben Lösung einen in Redis pro Sitzung gespeicherten Hash verwenden, wie in dieser anderen Antwort angegeben (nicht sicher, ob dies effizienter wäre, wenn sich viele Benutzer anmelden).

Klingt es schrecklich kompliziert? es tut mir an!

Haftungsausschluss: Ich habe Redis nicht verwendet.

Jose PV
quelle
-1

Wenn Sie Axios oder eine ähnliche versprechungsbasierte http-Anforderungsbibliothek verwenden, können Sie das Token im Front-End innerhalb des .then()Teils einfach zerstören . Es wird im Antwortteil .then () gestartet, nachdem der Benutzer diese Funktion ausgeführt hat (der Ergebniscode vom Serverendpunkt muss in Ordnung sein, 200). Nachdem der Benutzer bei der Suche nach Daten auf diese Route geklickt hat und das Datenbankfeld user_enabledfalsch ist, wird das Token zerstört, und der Benutzer wird sofort abgemeldet und kann nicht mehr auf geschützte Routen / Seiten zugreifen. Wir müssen nicht warten, bis das Token abläuft, während der Benutzer dauerhaft angemeldet ist.

function searchForData() {   // front-end js function, user searches for the data
    // protected route, token that is sent along http request for verification
    var validToken = 'Bearer ' + whereYouStoredToken; // token stored in the browser 

    // route will trigger destroying token when user clicks and executes this func
    axios.post('/my-data', {headers: {'Authorization': validToken}})
     .then((response) => {
   // If Admin set user_enabled in the db as false, we destroy token in the browser localStorage
       if (response.data.user_enabled === false) {  // user_enabled is field in the db
           window.localStorage.clear();  // we destroy token and other credentials
       }  
    });
     .catch((e) => {
       console.log(e);
    });
}
Dan
quelle
-3

Ich speichere nur das Token in der Benutzertabelle, wenn ich mich anmelde, aktualisiere ich ein neues Token und wenn die Authentifizierung gleich dem aktuellen JWT des Benutzers ist.

Ich denke, das ist nicht die beste Lösung, aber das funktioniert für mich.

Vo Manh Kien
quelle
2
Natürlich ist es nicht das Beste! Jeder, der Zugriff auf die Datenbank hat, kann sich leicht als jeder Benutzer ausgeben.
user2555515
1
@ user2555515 Diese Lösung funktioniert einwandfrei, wenn das in der Datenbank gespeicherte Token verschlüsselt ist, genau wie jedes in der Datenbank gespeicherte Kennwort. Es gibt einen Unterschied zwischen Stateless JWTund Stateful JWT(der Sitzungen sehr ähnlich ist). Stateful JWTkann von der Pflege einer Token-Whitelist profitieren.
TheDarkIn1978