Azure AD B2C 管理员代客手机号OTP验证方案可行性及更新限制咨询

1. 现有基于Profile Edit Policy的实现方案合理性评估 #

这套方案最开始做基础功能验证的时候，是可以跑通流程的：Profile Edit Policy本身支持在用户编辑个人属性时，通过内置步骤完成手机号、邮箱的OTP校验，管理员只要有该策略的访问权限，确实可以靠修改自身字段完成单次验证动作。但从生产长期落地的角度，这套逻辑完全不具备可行性，核心问题集中在三点：

• 没有形成有效数据闭环：按原方案，管理员每次验证客户号码时，都是把客户的手机号、邮箱写到自己账号的个人属性字段里，等验证完成后下次替换成新客户的号码，之前验证过的客户联系方式不会关联到任何真实的客户档案上——等于花时间走完全部验证流程，最后根本没有留存对应客户的有效验证记录，验证动作本身没有实际业务价值。
• 存在极高的安全风险：管理员账号本身的MFA绑定手机号会被反复替换为客户的联系方式，一旦后续该管理员登录时触发MFA校验，系统会直接把登录OTP发送到最后绑定的客户号码上，相当于管理员账号的控制权直接泄露给了最后一位被验证的客户，完全违反账号安全的最小权限原则。
• 操作效率极低且容易触发拦截：每验证一个客户就要走一遍完整的个人资料编辑、OTP校验、保存流程，没有批量处理能力，验证量稍大就会碰到平台的频率限制，操作成本极高。

更合理的落地方向：不需要把客户的联系方式绑定到管理员账号上，可基于Azure AD B2C的自定义用户旅程能力，把“联系方式OTP校验”环节从用户资料编辑流程中抽离出来，做成独立的无状态校验接口：管理员在业务页面输入客户的手机号/邮箱，直接调用接口完成OTP真实性核验，核验结果直接写入对应客户的属性档案，既不占用管理员的账号信息，也能做到验证结果和客户身份一一映射，安全和效率都能满足生产要求。

2. Azure AD B2C关于MFA绑定号码更新的平台限制 #

平台不存在专门针对“每日MFA绑定号码更新次数”的公开、可独立配置的规则，但实际运行中存在两类强关联的频率限制，会直接影响这类操作的可执行频次：

• OTP发送维度的限制：不管是登录MFA校验，还是修改联系方式时触发的短信、邮箱OTP校验，B2C对单租户有默认的防刷阈值，常规下单接收号码1小时内最多可接收10次OTP短信/邮件，超过阈值就会触发临时发送拦截，短时间内无法再发起新的OTP请求。
• 用户属性更新维度的限制：单个用户的核心联系方式类属性（绑定手机号、绑定邮箱），每日通过OTP完成校验关联的次数存在隐含阈值，常规默认每个用户每天最多完成10次该类属性的校验绑定，超过阈值后当天再次发起绑定请求会被策略直接阻断，无法完成后续流程。

所有这些限制都是平台内置的基础防护规则，没有管理员层面的豁免通道，也无法通过自定义策略配置绕过。

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