如何实现JWT一次性密码重置且无需在载荷存储密码信息

你当前方案的核心思路（密码更新后旧重置链接自动失效）本身是可行的，只需要调整JWT的payload结构和校验逻辑，完全不需要在服务端新增任何存储字段，也不需要额外保存密码相关的重置标记：

• 生成重置链接的JWT时，不要在payload里存完整的密码哈希，只需要存当前用户已存密码哈希的特征片段、用户邮箱即可，签名和过期时间配置保持原有逻辑：

// 生成token前，先根据邮箱查到用户现有记录，取已存储的密码哈希计算特征值
const crypto = require('crypto');
// 用服务端密钥对现有密码哈希做一次HMAC摘要，取固定长度片段作为标记
const resetMarker = crypto
  .createHmac('sha256', secret)
  .update(user.passwordHash)
  .digest('hex')
  .slice(-16);
const resetToken = jwt.sign(
  { email: user.email, resetMarker },
  secret,
  { expiresIn: "1d" }
);

• 校验重置请求的逻辑按如下顺序执行：
  1. 调用jwt.verify(req.body.token, secret)校验JWT签名合法性和是否过期，校验不通过直接返回400错误
  2. 从解析后的JWT payload中取出用户邮箱，查询数据库对应用户记录
  3. 用和生成token时完全相同的逻辑，对数据库中当前存储的该用户密码哈希计算resetMarker
  4. 比对计算出的resetMarker和JWT payload中携带的resetMarker：二者一致则允许更新为新密码，不一致则说明该链接已经被使用过（或签发后用户密码已经通过其他渠道修改），直接返回400错误

方案说明 #

• 零额外存储开销：用到的密码哈希是用户表本来就必须存储的登录校验字段，不需要新增重置token表，也不需要给用户表加任何重置相关的字段，完全符合不额外存储密码相关字段的要求
• 天然满足一次性要求：一旦用户通过该链接（或其他任何渠道）修改了密码，数据库中存储的密码哈希就会完全变更，计算出的resetMarker自然和旧JWT中携带的不匹配，旧链接直接失效，和你原有逻辑的效果完全一致
• 安全性比原方案更高：JWT payload仅做Base64编码可被直接解码，原方案直接存储完整密码哈希，如果链接泄露会导致攻击者拿到完整哈希跑彩虹表碰撞；本方案只存HMAC后的短片段，既无法反推原始密码，也无法反推完整密码哈希，没有泄露风险
• 碰撞概率可忽略：16位十六进制片段的碰撞概率为1/18446744073709551616，加上HMAC本身绑定服务端密钥，不存在被构造碰撞的可能。如果对安全性要求更高，把截取长度调整为24位即可进一步降低碰撞概率。

内容的提问来源于stack exchange，提问作者user349557