OTP.Net无状态调用时如何验证上次发送的OTP验证码？

跨API调用验证失败核心是对TOTP工作逻辑和OTP.Net的使用方式存在理解偏差，以下直接对应问题给出解答：

1. 跨API调用验证返回false的原因&正确验证方式 #

同方法内生成+立刻验证返回true，是因为两个操作落在同一个TOTP时间窗口（默认30秒）内，且使用了相同密钥，自然可以校验通过。跨调用返回false，90%以上是以下两个原因：

• 两次调用使用的_otpSecretKey不是同一个值。不少人写测试代码时会在Totp实例初始化时临时生成随机密钥，第一次生成OTP用的密钥，在第二次API调用时已经被重新赋值/重新生成，两边密钥不一致，哈希计算结果必然不匹配。
• 两次调用间隔超过默认校验的时间窗口，且没有配置容忍偏移。默认VerifyTotp方法只校验当前时间所在的30秒窗口内生成的验证码，如果用户输入延迟、服务器时间存在微小偏差，跨了时间窗口就会校验失败。

正确的验证实现步骤：

• 密钥必须固定且和用户绑定，禁止每次调用临时生成。
• 校验时先根据当前操作的用户ID，取出该用户对应的专属密钥初始化Totp实例。
• 配置合理的验证容忍窗口，覆盖正常的用户输入延迟和服务器时间差，建议允许向前偏移1个时间窗口（即覆盖前30秒+当前30秒共1分钟内的有效验证码，不要开向后偏移，避免扩大攻击面）。
• 校验通过后必须记录本次匹配到的时间步值，防止同一个验证码被重复提交利用（防重放攻击）。

参考实现代码：

// 从持久化存储中读取当前待验证用户的专属TOTP密钥
byte[] userSecret = _userRepository.GetTotpSecretByUserId(currentUserId);
var totp = new Totp(userSecret);
// 配置验证窗口：允许校验前1个时间窗口的验证码，不允许未来窗口的验证码
bool isVerified = totp.VerifyTotp(userInputCode, out long matchedTimeStep, new VerificationWindow(previous: 1, future: 0));

if (isVerified)
{
    // 校验该用户是否已经使用过这个时间步的验证码，防止重放
    bool isUsed = _redisCache.Exists($"totp_used:{currentUserId}:{matchedTimeStep}");
    if (isUsed)
    {
        // 验证码已被使用，返回验证失败
        return Unauthorized();
    }
    // 标记该时间步的验证码已使用，过期时间设为2分钟足够覆盖窗口有效期
    _redisCache.Set($"totp_used:{currentUserId}:{matchedTimeStep}", 1, TimeSpan.FromMinutes(2));
    // 执行后续登录/校验通过业务逻辑
}

2. 是否需要存储OTP、多用户区分逻辑 #

分两种常见使用场景判断：

场景1：标准TOTP动态验证码（类似身份验证器APP的30秒刷新验证码） #

不需要把生成的OTP验证码存入数据库。
TOTP的设计本身就是无状态的：服务端和用户端提前共享同一个密钥，双方基于相同的时间规则独立计算验证码，不需要服务端存储生成的验证码就能完成校验。
多用户区分的核心就是给每个用户分配全局唯一的专属密钥：用户绑定TOTP时生成一个随机密钥，和用户ID绑定存在数据库中，校验时通过用户ID取出对应密钥计算即可，不同用户密钥不同，生成的验证码自然隔离。

场景2：短信/邮件发送的一次性验证码（有效期通常5分钟左右） #

这种场景不建议硬套TOTP逻辑，更合理的实现是：

• 生成6位随机数字验证码，将验证码、用户ID、过期时间、已使用状态存在缓存/数据库中
• 校验时直接查询对应用户的未过期、未使用验证码，和用户输入比对即可
  如果一定要用OTP.Net实现，需要把TOTP的时间步长改成和验证码有效期一致（比如300秒），但依然需要存储已使用的时间步来防重放，相比直接存验证码没有明显优势。

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