Jwt 将过期代币放入黑名单表是一个好主意吗？

首先，这是我当前的身份验证流的外观

用户登录

用户获得分配并存储在数据库中的刷新令牌（长寿命7d）

客户机收到一个accestoken（短期，2h），并将其存储为cookie。客户端还接收加密的用户ID AES，并存储 它就像一块饼干

只要访问令牌未过期，用户将继续使用令牌浏览网站

令牌过期

过期的访问令牌被发送到刷新端点，用户标识（Aes加密）也被发送到刷新端点，这两个标识当前都存储在out Cookie中

服务器解密用户ID并通过使用out userId从数据库中选择刷新令牌来检索与用户对应的刷新令牌

现在我们在服务器中有了refreshtoken和accesstoken，所以我们刷新了token，并发回了新的accesstoken。我们还生成一个新的refreshtoken，并用新的refreshtoken覆盖数据库中的旧refreshtoken

我的问题基本上与最后一步有关。因为这些刷新令牌在技术上仍然有效，因为它们有很长的过期时间。我可以在我的数据库中创建一个名为“blacklisted_tokens”或类似的表，并将令牌的值存储在那里吗？然后在生成新的访问令牌之前，它应该检查刷新令牌是否在该数据库中，这意味着它将被列入黑名单

这是authflow图

我的问题基本上与最后一步有关。自从那些 刷新令牌在技术上仍然有效，因为它们具有很长的 有效期。我可以在数据库中创建一个名为 “被列入黑名单的_代币”或类似的东西，然后将 代币的价值？然后就在生成新访问之前 在检查刷新令牌是或不是之前，它应该先检查该令牌 这意味着它将被列入黑名单

不建议这样做，因为生成2个相同令牌的概率很低，向后端添加非必要的附加进程不是一个好主意，并且在大规模令牌重新生成中存在性能问题（很多用户）

此外，代币还带有一个标识（id），可以降低安全风险

如果我是你，我会把新令牌重新写入旧令牌

威胁代币的最重要的网络攻击类型是，通过执行以下步骤，这种攻击的概率几乎为零：

• SSL证书
• 过期令牌和重新生成
• 苛刻的要求

盐 在密码学中，salt是用作附加数据的随机数据 输入一个单向函数，用于散列数据、密码或密码 密码短语。盐用于保护存储中的密码

---

这在jwt令牌身份验证中是不可能的。可能是在oauth工具中实现的。