JWT 使用数据库处理过期

Posted 2023-03-07

【中文标题】JWT 使用数据库处理过期

【英文标题】：JWT handling expiration with a database

【发布时间】：2016-08-26 06:17:07

【问题描述】：

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

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

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

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

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

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

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

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

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

【参考方案1】：

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

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

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

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

【讨论】：

“客户端凭据”是什么意思？这些凭据包括哪些信息？

将客户端凭据视为客户端应用程序本身的一种用户名/密码。它们标识的是应用程序而不是用户。

如果黑客获取了客户端的用户名/密码会怎样？你能举个例子说明这如何与 Web 应用程序一起工作吗？

使用客户端凭据和刷新令牌，您可以从授权服务器获取新的访问令牌。这就是为什么刷新令牌只发给机密（服务器端）客户端。对于公共客户端（例如 SPA 应用程序），浏览器通常与授权服务器有一个 cookie 会话。

我还是一头雾水，这是我拥有的SPA，目前它使用用户登录来获取令牌客户端并使用它来访问资源。您是说我需要在客户端存储第二个令牌（刷新令牌）吗？拥有此刷新令牌和访问令牌有什么区别？难道黑客不能同时窃取刷新令牌和访问令牌吗？