Asp.Net Core 中使用 SMS 服务替代邮件实现密码重置的技术问题

1. 如何使用SMS服务发送密码重置令牌 #

两种实现路径可以选择，分别对应不同的令牌生成逻辑：

• 自定义短令牌映射方案：生成原生长令牌后，将令牌与用户ID绑定存储在缓存/数据库中，生成唯一的6位数字短码映射关系，仅将短码通过短信发送给用户。用户提交短码时，后台通过短码查询对应的原始长令牌，再调用Identity的密码重置验证逻辑即可。
• 替换Identity令牌提供程序方案：自定义实现IUserTwoFactorTokenProvider<TUser>接口，将密码重置场景的令牌生成逻辑调整为输出6位数字，直接调用userManager.GeneratePasswordResetTokenAsync(user)即可得到短令牌，直接通过短信发送，验证时直接传入用户输入的短码即可。

2. 两种令牌方案的合理性对比 #

不推荐直接发送原生长令牌 #

UserManager.GeneratePasswordResetTokenAsync默认生成的令牌长度通常在100字符以上，直接通过短信发送存在两个核心问题：

• 用户需要手动输入长串乱码字符，操作成本极高，体验极差
• 长文本容易触发短信多段拆分，增加发送成本和接收失败概率，完全不符合短信场景的使用习惯

两种可行方案的优劣 #

自定义6位短令牌+映射原生长令牌（优先推荐）

实现逻辑：自行维护短令牌的生成、存储、过期、验证逻辑，短令牌验证通过后，后台再主动调用原生方法生成长令牌完成密码重置，全程不向用户暴露长令牌。

• 优势：不需要修改Identity的默认配置，可同时兼容邮件长令牌、短信短令牌的多渠道重置需求，可灵活配置短令牌的有效期、重试次数、防爆破规则，安全性可控，实现难度低。
• 劣势：需要自行维护短令牌的存储和生命周期管理。

替换Identity默认令牌提供程序生成短令牌

实现逻辑：通过依赖注入替换密码重置场景的令牌提供程序，让原生方法直接输出6位数字令牌，复用Identity自带的令牌验证和过期逻辑。

• 优势：不需要自行维护令牌存储，完全复用Identity的内置能力。
• 劣势：如果需要同时保留邮件场景的长令牌逻辑，需要配置多套令牌提供程序，实现复杂度更高。

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