是否有充分的理由不将密码重置令牌存储在像 redis 这样的键值存储中？答案

【问题标题】：Is there a good reason not to store password reset tokens in a key value store like redis?是否有充分的理由不将密码重置令牌存储在像 redis 这样的键值存储中？
【发布时间】：2021-03-19 01:17:50
【问题描述】：

通常我将哈希密码重置令牌存储在 MySQL 等数据库中。

在我当前的应用程序中，我使用 JWT 来减少数据库查询的数量。我还使用 Redis 来跟踪有效的 JWT，现在我想知道为什么我不应该只将密码重置令牌保存在 Redis 中并将令牌映射到用户 ID + 时间戳（以拒绝旧令牌）。

我能想到的唯一原因是内存使用。

还有其他理由不这样做吗？

【问题讨论】：

标签： redis jwt jwt-auth one-time-password

【解决方案1】：

你会引入一个故障点，即Redis。

如果跟踪有效的 JWT 是检查 JWT 是否撤销的一种方法，那么您可能已经遇到了那个故障点。如果 Redis 不可用会怎样？您要么拒绝访问（因此是故障点），要么接受任何经过验证的 JWT 为有效（未撤销）。

如果后者为真，在 Redis 中存储重置令牌只会使依赖关系变得明确：如果 Redis 已关闭，则无法更改密码。

【讨论】：

如果 redis 不可用，您将无法进行身份验证，是的，也无法重置密码，但是如果我使用 mysql，那么故障点将是数据库，那么使用数据库有何不同？
我的理解是密码重置令牌本身就是一个 JWT。然后，您可以对映射（到用户 ID）进行签名，也可以添加时间戳 (iat)。我弄错了吗？
无论如何，您的数据库本身就是一个故障点。 Redis 将是一个新的故障点。
啊，好吧，我明白了，但要解决这个问题，我可以使用数据库作为后备吗？密码重置令牌不是 JWT，它只是一个可以（仅一次）用于获取 JWT 的令牌（令牌是一个 URL 参数，是发送给用户的重置链接的一部分，我不想要 JWT一个可能被记录的获取请求）
可以使用数据库。由于此查找用于密码重置，因此在正常情况下它不应该是性能问题。