我应该将JWT令牌存储在Redis中吗？
我正在使用ExpressJS，Mongodb（Mogoose）构建应用程序。应用程序包含访问用户之前必须对其进行身份验证的路由。
目前，我已经编写了一个快速的中间件来做同样的事情。在这里，借助JWT令牌，我正在进行mongodb查询以检查用户是否已通过身份验证。但是感觉这可能会在我的数据库上增加不必要的请求负载。
我应该针对此特定任务集成redis吗？
会改善API性能吗？还是应该继续使用现有的mongodb方法？
如果我对此有更多的见解会很有帮助。
问题答案：
TLDR：如果您想在某个时候撤销令牌，可以，将其存储在像Redis这样的快速存储器中。
使用JWT的有据可查的缺点之一是，没有简单的方法可以撤销令牌，例如，如果用户需要注销或令牌已被盗用。撤消令牌意味着要在某个存储中查找令牌，然后决定下一步要做什么。由于JWT的要点之一是避免往返于db，因此一个很好的折衷方案是将其存储在比rdbms少的负担下。对于Redis而言，这是一项完美的工作。
正如评论中所建议的那样，一种好的方法是使该列表成为黑名单（即，无效令牌的列表）。根据每个请求，您将查找列表，以确保其中没有令牌。通过使用概率算法存储令牌，可以在查找步骤中进一步改善内存空间和性能。一个简单的实现是不将整个令牌存储在redis黑名单中。只需存储令牌的前几个字符。然后，您可以使用更持久的解决方案（文件系统，rdbms等）存储黑名单的完整版本。这是一个乐观的查询，仍然可以快速告诉您黑名单中不存在令牌（这是更常见的情况）。如果要查找的令牌恰巧与redis黑名单中的一项匹配（因为其前几个字符匹配），然后转到持久性存储上的额外查找。另一个更有效且相对容易实现的算法称为布隆过滤器。
-
我正在使用vue.js和vuex开发一个应用程序，它使用JWT令牌对JSON API服务器进行身份验证。所以我想知道存放JWT代币的最佳做法是什么？ 如果我将其存储在vuex商店中，则页面刷新后它会丢失，因此用户需要再次登录，这不是很方便。 如果我将其存储在浏览器的本地存储中，它会在下次登录之前被弃用，然后假设身份验证令牌的组件会混淆。我不知道如何处理这个问题。 感谢你对此的暗示。
-
我正在实现一个需要身份验证的REST服务。我正在使用JWT。 现在，Android应用程序在登录时发送一个请求，获得一个令牌，并且必须在每个后续请求的头中发送令牌。 我的问题是，如何存储令牌，或者我应该将其存储在哪里？ 共享偏好 SQLite数据库 归档 最好的做法是什么？还是我完全错了？
-
我正在用Django和angular构建一个应用程序。目前，我正在本地存储上存储后端发布的JWT。但是，我担心XSS攻击。我应该使用仅HTTP cookie存储令牌吗？我还考虑将令牌存储在auth服务类的变量字段中。但我不能完全确定angular是否在整个应用程序中共享该服务。我的身份验证服务是否只有一个实例？
-
我自己想了一个实现，但觉得有点过头了，而且笨重？ 我将使用用户ID作为密钥 Id然后在value部分中存储JWT令牌的hashmap。 示例 null null 这意味着在每个对受保护的apiendpoint的请求中，我必须按userId进行搜索，反序列化hashmap,循环遍历hashmap并尝试匹配在头中发送的JWT。这看起来像是一个很大的工作？还有别的办法吗？ 如果一个用户想要注销，那么这个
-
我正在阅读关于JWT Web令牌作为响应用户的访问令牌的文章。其中一些提到Web令牌应该能够被用户解码。 这是否意味着解密整个web令牌不是一个好的做法？例如，我假设将下面的JWT web令牌返回给用户，在那里可以对这段信息进行解码。 但是，我觉得我不想让用户能够解码他/她的访问令牌，所以我使用另一种加密算法将所有内容加密为另一种形式，如下所示并传回给用户。 所以，当我在服务器中得到这个访问令牌并
-
在处理基于浏览器的应用程序时，关于安全存储JWT令牌的主题已经提出了很多问题。大家一致认为，应该使用仅限http的安全cookie。然而，当涉及短期访问令牌和长期刷新令牌时，存储JWT令牌似乎存在许多变化。 我发现了以下变化： 1.仅将JWT访问令牌和刷新令牌存储在http安全cookie中 赞成的意见： 无法从Javascript访问访问令牌和刷新令牌 欺骗： 引入CSRF漏洞，因此也必须添加C