it-swarm.com.de

Statuslose Authentifizierung mit JWT: Das Aktualisierungstoken ist nicht zustandslos

In meiner aktuellen Architektur gibt mein Backend eine JWT an den (mobilen) Client zurück. Der Hauptgrund für die Entscheidung für eine JWT ist die zustandslose Authentifizierung, d. H. Der Server muss keine Daten in der Sitzung/Datenbank speichern, was weniger Overhead- und Skalierbarkeitsprobleme bedeutet.
Eine übliche Strategie besteht darin, sich beim Benutzer anzumelden und die kurzlebige JWT (ungefähr 15 Minuten - wie ich gelesen habe) zusammen mit einem Aktualisierungstoken zurückzugeben, das der Benutzer im Client speichert. Das Aktualisierungstoken läuft nie ab und kann nur widerrufen werden. Der Zweck wäre, zu vermeiden, dass ein langlebiger JWT zu oft über das Kabel gesendet wird, und den JWT erst nach Ablauf zu aktualisieren. Wenn ein Angreifer den kurzlebigen Token ergreift, ist das Angriffszeitfenster kurz.

Das Problem ist, dass diese Geschichte voller Löcher zu sein scheint, wenn ich darüber nachdenke. Bitte helfen Sie mir zu klären.

  1. Eine Ablaufzeit von 15 Minuten würde bedeuten, dass einige Benutzer genauso gut 10 Mal pro Tag ein Aktualisierungstoken über das Kabel senden könnten. Dies ist möglicherweise genauso häufig, wie einige Benutzer Anforderungen mit einem regulären, kurzlebigen Zugriffstoken stellen würden. Daher erscheint das Argument des Aktualisierungstokens fraglich.
  2. Wenn Sie SSL in Frage stellen, weiß ich nicht, warum so viele Unternehmen die Basisauthentifizierung verwenden. Um JWT mit einem Aktualisierungstoken zu verwenden, sollten Sie wahrscheinlich trotzdem HTTPS verwenden.
  3. Was ist der Vorteil von JWT, wenn Sie dann ein Aktualisierungstoken in der Sitzung/Datenbank speichern müssen, um dem Client ein neues JWT auszugeben. In diesem Fall fungiert das Aktualisierungstoken als eine Art Kennwort (obwohl mir klar ist, dass es nicht genau dasselbe ist), das im Backend gespeichert wird. Dies macht den Authentifizierungsfluss im Wesentlichen zustandsbehaftet und scheint den Vorteil der Verwendung von JWT insgesamt zu beeinträchtigen. Mit einer kurzen Ablaufdauer von 15 Minuten bedeutet dies außerdem, dass Sie viel Overhead haben und fast jedes Mal, wenn Sie Ihr Telefon überprüfen, ein aktualisiertes Zugriffstoken erhalten müssen, wenn ein Intervall von 30 Minuten vorliegt. Es gibt nicht nur den Overhead zum Überprüfen des gespeicherten Aktualisierungstokens, sondern Sie müssen auch prüfen, ob das Aktualisierungstoken auf der schwarzen Liste steht, was einen weiteren Leistungsaufwand bedeutet. (Bearbeiten: Die letzte Prüfung kann entfernt werden, indem beim Aktualisieren nur das Aktualisierungstoken aus der Datenbank entfernt wird.).
  4. Ein Aktualisierungstoken erfordert mehrere Server-Roundtrips:
    • 401 wird zurückgegeben, wenn das Zugriffstoken abgelaufen ist (Ressourcenserver).
    • Auf dem Authentifizierungsserver muss ein neues Zugriffstoken angefordert werden
    • Die Anforderung an den Ressourcenserver muss erneut initiiert werden.

Kann mir jemand erklären, was ich hier vermisse?

15
Trace

Einer der Hauptkritikpunkte an zustandslosen Sitzungstoken ist das Fehlen einer sicheren Abmeldung. Ein separates Zugriffs-/Aktualisierungstoken ermöglicht einen Kompromiss. Sie können den Datenbankzugriff erheblich reduzieren und gleichzeitig eine sichere Abmeldefunktion mit einer Verzögerung von 15 Minuten verwenden.

Das Design schützt nicht vor Sitzungsentführungen, d. H. Der böswilligen Erfassung des Tokens. Verwenden Sie einfach SSL, es ist heutzutage allgegenwärtig.

Mit etwas Sorgfalt können Sie die Anzahl der Hin- und Rückfahrten reduzieren. In vielen Client-HTTP-Bibliotheken können Sie eine proaktive Authentifizierung durchführen, wodurch der zusätzliche Roundtrip zum Erhalt eines 401 vermieden wird.

Ich stimme zu, dass es kein besonders vernünftiges Design ist. Die meisten Websites sind ohnehin datenbankintensiv, sodass das Überprüfen eines Tokens bei jeder Anforderung nicht viel mehr Aufwand bedeutet. Und obwohl das Grundkonzept der Zugriffs-/Aktualisierungstoken sicher ist, mache ich mir Sorgen, dass die zusätzliche Komplexität zu Implementierungsfehlern führt.

11
paj28

Sofern es keine anderen Antworten auf diese Frage gibt, besteht meine derzeitige Lösung darin, die Kompromisse zwischen Sicherheitsrisiko und Leistung zu bewerten.

Meine Hauptüberlegung ist es, das Zeitfenster des "kurzlebigen" JWT-Zugriffstokens von 15 Minuten auf einen Tag zu verlängern.
Dies vorausgesetzt, dass HTTPS erforderlich ist und dass Anforderungen nur intern gestellt werden, d. H. Die Token werden nicht domänenübergreifend übertragen.

Dies bedeutet, dass die Token-Aktualisierung in Bezug auf die Leistung nur einmal am Tag erfolgt. Theoretisch sollte SSL in meinem Fall eine ausreichende Sicherheit bieten. Ein einziges Tag Angriffsfenster ist lediglich eine Sicherheitsmaßnahme zusätzlich zu etwas, das überhaupt nicht passieren sollte.

Obwohl Aktualisierungstoken den Authentifizierungsprozess im Wesentlichen zustandsbehaftet machen, kann dies akzeptabel sein, da die meisten Anforderungen (in diesem Fall über einen Tag) an den Ressourcenserver weiterhin über das JWT erfolgen.

1
Trace