JWT使用数据库处理过期

Question

我最近一直在思考同一个问题，想知道我的令牌解决方案是否有什么重大缺陷:

• 将过期时间设置为较低值（约15分钟）
• 每个生成的JWT也被添加到每个用户的“issuedTokens”集合/表中

在 JWT 验证期间，如果过期已过，将从服务器返回“过期”响应（例如，正文中带有“过期”的 401）。当客户端收到此状态时，它应该启动一个刷新过程，该过程将过期的令牌换成新的令牌。

服务器上的刷新endpoint应采用过期令牌并执行以下操作：

1. 验证令牌（到期除外）
2. 检索用户ID并检查令牌是否在其发布的令牌集合中
3. 发布新的JWT
4. 从集合中删除过期的令牌并添加新的令牌

如果这些步骤中的任何一个失败，应向客户端发送未经授权的错误，然后需要再次登录。

为了防止不断累积已颁发的令牌，我们可以在issued tokens集合中的令牌上设置TTL。将TTL值设置为在要求再次登录之前登录应该处于活动状态的时间。

此方法不会命中数据库，除非您继续尝试刷新过期的令牌。在这种情况下，您可以使用失败令牌的缓存黑名单。如果将其视为缓存层，则可以驻留在应用程序本身旁边。

这绝对只是我即将测试的一个正在进行的解决方案。让我知道你的想法。

Answer 1

我认为这种方法有几个问题。首先，如果我能够窃取任何人的JWT令牌，我可以通过调用您的endpoint来不断获得新的令牌。

例如，OAuth2 通过使用刷新令牌时要求客户端发送客户端凭据来缓解此问题。某些公共客户端库使用客户端和授权服务器（而不是资源 （API） 服务器）之间的会话 cookie 来续订令牌。

另一个问题当然是所有JWT令牌的集合，这就像一个凭证数据库。如果有人设法窃取了它，他们将以您的任何用户的身份访问您的应用程序。

使用自己的身份验证机制是非常困难的，因此风险很大。