Die JWT-Spezifikation erwähnt eine jti-Behauptung, die angeblich als Nonce verwendet werden kann, um Wiederholungsangriffe zu verhindern:

Der Anspruch "jti (JWT ID)" stellt eine eindeutige Kennung für die JWT bereit. Der Bezeichnerwert MUSS so zugewiesen werden, dass mit vernachlässigbarer Wahrscheinlichkeit sichergestellt ist, dass derselbe Wert versehentlich einem anderen Datenobjekt zugewiesen wird. Wenn die Anwendung mehrere Emittenten verwendet, MÜSSEN Kollisionen auch zwischen Werten verschiedener Emittenten verhindert werden. Mit dem jti-Claim kann verhindert werden, dass das JWT erneut abgespielt wird. Der jti-Wert unterscheidet zwischen Groß- und Kleinschreibung. Die Verwendung dieses Anspruchs ist OPTIONAL.

Meine Frage ist, wie ich dies implementieren würde? Muss ich die zuvor verwendeten JTIs speichern und bei jeder Anforderung eine neue JWT ausstellen? Wenn ja, ist das nicht ein Misserfolg des Zwecks von Zeugen Jehovas? Warum sollte ein JWT verwendet werden, anstatt nur eine zufällig generierte Sitzungs-ID in einer Datenbank zu speichern?

My REST API hat eine Mongo-Datenbank und ich bin nicht dagegen, eine Redis-Instanz hinzuzufügen. Gibt es eine bessere Authentifizierungsoption als JWT? Ich möchte hauptsächlich keine Passwörter auf dem Client speichern, was die HTTP-Authentifizierung als Option ausschließt. Da ich mich jedoch eingehender mit diesem JWT-Material beschäftige, habe ich das Gefühl, dass eine benutzerdefinierte Token-Implementierung oder ein anderer Standard besser sein könnte meinen Bedürfnissen entsprechen. Gibt es Knoten- / Express-Pakete für die tokenbasierte Authentifizierung, die die Token-Sperrung und das Drehen von Token unterstützen?

Würde mich über jeden Rat freuen.