短答:使用电子邮件的单用重置链接作为大部分SaaS登录恢复的默认,仅在用户可能真正缺乏电子邮件访问或产品已经维持已核实的电话号码时,才会添加短信OTP.
电子邮件通常是比较简单的系统,因为登录标识符,恢复目的地,支持工作流程可以留在一个频道.
短信可以缩短交互,但增加了电话号码生命周期,消息分解,区域同意,以及交付状态工作. “Cheaper”取决于您的流量和故障率,所以模型完成回收而不是发送信息。
这是一项追回决定,而不是通知优先。
目标是在不将延迟消息,过期证书,或回收的电话号码转换为账户接管或支持队列的情况下,将合适的人返回账户.
我已经做了足够的垃圾邮件过滤, 速率限制, 和OTP的提供缺口, 将信道作为系统的一部分, 而不是系统本身。
SaaS密码恢复流程应使用什么:电子邮件API或短消息OTP?
从您已经可以信任的账户数据开始 。
如果每个用户都用电子邮件地址签名并更改该地址属于受控操作,那么一个电子邮件重置链接就会产生更小的数据表面.
该服务产生高通量的单用代币,只存储其被保护的代表物,发送链接,并在短失效前接受该代币一次.
然后浏览器将用户移动到一个密码更改会话中.
屏幕上有一个短消息OTP流看起来很紧凑,然而后端还有更多的问题要回答.
电话最近被证实了吗?
用户可以在不签名的情况下更新它吗 ?
国家守则如何正常化?
当一个数字被重新分配时会发生什么?
支援队对丢失装置的人是否有安全路径?
六位数的表格不会使这些政策决定消失.
所以,默认是直接的。
当电子邮件是稳定的账户标识符时先选择电子邮件, 恢复是偶尔的 。
当服务有合理的理由收集和不断核实电话号码,或者当一个只用电子邮件的路径会挤出一个有意义的用户群时,将短消息视为一个额外的路径.
不要仅仅因为输入一个短代码在演示中感觉更快而加入短消息.
当用户经常失去访问识别他们的邮箱的机会时, 在这种情况下,可能需要一个经过单独核实的回收系数或支助援助程序。
当手机所有权在产品环境中的证据不足,当区域短信业务没有配备人员,或者当收集电话号码将产生不相称的隐私和合规工作时,短信也不适用.
两个频道都不是普遍倒退。
送出限制在屏幕前出现 对于电子邮件,送出开始于域名对齐和消息完整性.
DKIM让一个签名域承担消息的责任,让接收者检测到在中转中签名内容的更改.
这是一种有用的基础设施,但有效的签名并不能保证信息会到达收件箱,也不能保证发送者是可信的。
恢复设计仍需要稳定的发送身份,保守的内容,回弹处理,压制,以及整个路径周围的监测.
密码重置邮件也应是无聊的.
保持目的明显,避免不必要的跟踪,不包含当前密码,并在不暴露账户状态的情况下明确到期.
请求的结束点应对现有和不存在的账户作出同样的公开答复。
否则,回收表将成为电子邮件地址发现工具。
短信有不同的物理约束:编码改变能力.
单个GSM-7消息最多可包含160个字符,而UCS-2则会将这个信息减少到70个.
密文为分块保留字符,每段留下153个GSM-7或67个UCS-2字符.
卷起的引文,非拉丁名,或翻译的句子可以