JWT 使用数据库处理过期

Question

我最近一直在考虑同样的问题，想知道我的令牌解决方案是否存在任何重大缺陷：

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

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

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

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

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

为了防止已发行代币的无休止累积，我们可以在已发布代币集合中的代币上设置一个 TTL。将 TTL 值设置为在要求再次登录之前登录应该处于活动状态的时间量。

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

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

Answer 1

我发现这种方法存在几个问题。首先，如果我能够窃取任何人的 JWT 令牌，我可以通过调用您的端点来继续获取新令牌。

OAuth2 例如通过在使用刷新令牌时要求客户端发送客户端凭据来缓解这种情况。 一些公共客户端库使用客户端和授权服务器（而不是资源 (API) 服务器）之间的会话 cookie 来更新令牌。

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

想出自己的身份验证机制非常难以正确，因此风险很大。