我应该将 JWT 令牌存储在 redis 中吗? [英] Should I store JWT tokens in redis?

查看:33
本文介绍了我应该将 JWT 令牌存储在 redis 中吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在用 ExpressJS 构建一个应用程序,Mongodb(Mogoose).应用程序包含用户必须在访问之前对其进行身份验证的路由.

I'm building an application with ExpressJS, Mongodb(Mogoose). Application contains routes where user has to be authenticated before accessing it.

目前我已经编写了一个快速中间件来做同样的事情.在这里,在 JWT 令牌的帮助下,我进行 mongodb 查询以检查用户是否已通过身份验证.但感觉这可能会给我的数据库带来不必要的请求负载.

Currently I have written a express middleware to do the same. Here with the help of JWT token I'm making mongodb query to check whether user is authenticated or not. but feel this might put unnecessary request load on my database.

我应该为这个特定任务集成 redis 吗?
它会提高 API 性能吗?或者应该继续使用现有的mongodb 方法?

should I integrate redis for this specific task?
does it will improve API performance? or should go ahead with existing mongodb approach?

如果我对此有更多见解会有所帮助.

would be helpful if I get more insights on this.

推荐答案

TLDR:如果您希望能够在某个时候撤销令牌,是的,请将其存储在诸如 Redis 之类的快速程序中.

TLDR: If you want the capability to revoke the token at some point, yes, store it in something fast like Redis.

使用 JWT 的一个有据可查的缺点是,如果例如用户需要注销或令牌已被泄露,则没有简单的方法来撤销令牌.撤销令牌意味着在某个存储中查找它,然后决定下一步做什么.由于 JWT 的要点之一是避免到 db 的往返,因此一个好的折衷方法是将其存储在比 rdbms 更省力的地方.这对 Redis 来说是一项完美的工作.

One of the well documented drawbacks of using JWT is that there's no simple way to revoke a token if for example a user needs to be logged out or the token has been compromised. Revoking a token would mean to look it up in some storage and then deciding what to do next. Since one of the points of JWT is to avoid round trips to the db, a good compromise would be to store it in something less taxing than an rdbms. That's a perfect job for Redis.

正如评论中所建议的,一个好的方法是将列表设为黑名单(即无效令牌列表).在每次请求时,您都会查找列表以确保其中不存在令牌.通过使用概率算法来存储令牌,您可以在查找步骤中进一步提高内存空间和性能.一种简单的方法是进行分层查找.例如,您可以拥有一个小型应用程序内商店,仅跟踪列入黑名单的令牌的前几个(例如 1 到 4 个)字节.然后 redis 缓存将跟踪相同令牌的稍微更完整的版本(例如前 2 到 8 个字节).然后,您可以使用更持久的解决方案(文件系统、rdbms 等)存储列入黑名单的令牌的完整版本.这是一种乐观查找策略,可以快速确认黑名单中不存在令牌(这将是更常见的情况).如果正在查找的令牌恰好与应用内黑名单中的项目匹配(因为它的前几个字节匹配),则继续在 redis 存储上进行额外查找,然后在需要时进行持久性存储.一些(或全部)存储可以实现为尝试或哈希表.另一个需要考虑的有效且相对简单的数据结构是称为布隆过滤器.

As suggested in the comments a good approach is to make the list a blacklist (i.e. a list of invalidated tokens). Upon each request you look up the list to ensure the token is not present in it. You can further improve on memory space and performance during the lookup step by using a probabilistic algorithm to store the token. A simple approach is to have layered lookups. For instance, you could have a small in-app store that only tracks the first few (e.g 1 to 4) bytes of your blacklisted tokens. Then the redis cache would track a slightly more complete version of the same tokens (e.g. first 2 to 8 bytes). You can then store a full version of the blacklisted tokens using a more persistent solution (filesystem, rdbms, etc). This is an optimistic lookup strategy that will quickly confirm that a token is absent from the blacklist (which would be the more common case). If a token being looked up happens to match an item in the in-app blacklist (because its first few bytes match), then move on to an extra lookup on the redis store, then the persistent store if need be. Some (or all) of the stores may be implemented as tries or hash tables. Another efficient and relatively simple to implement data structure to consider is something called a Bloom filter.

显然,如果您经常将数百万个持久令牌列入黑名单(这也可能表明您遇到了不同的问题),则必须采用上述方法.

Obviously, you'd have to adapt the above approach if you routinely blacklist millions of long-lasting tokens (which may also indicate that you have a different problem).

这篇关于我应该将 JWT 令牌存储在 redis 中吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆