Azure AD B2C场景下支持匿名用户的架构实现方案咨询

结论 #

Azure AD B2C目前没有支持「临时应用用户」场景的开箱即用功能，你之前尝试的自定义政策方案是官方推荐的标准实现路径，可通过优化步骤降低落地复杂度，也可以选择更轻量的替代方案快速满足需求。

轻量快速落地方案（无需自定义政策） #

如果可以接受匿名阶段的令牌由应用后端签发，完全不需要改动B2C侧配置，开发成本最低：

• 匿名访问阶段：后端生成唯一deviceID，自行签发短时效access token，仅授权匿名用户访问无需个人身份的受限接口，不需要和B2C交互
• 用户发起注册阶段：启动B2C标准注册用户流时，将deviceID作为查询参数附加到B2C授权请求URL中，开箱的B2C用户流支持配置传递自定义查询参数到最终的令牌声明中，注册完成后返回的id token会自带deviceID声明
• 账号绑定阶段：后端拿到带deviceID的B2C正式令牌后，直接将该deviceID对应的匿名用户数据和正式B2C账号绑定即可，无需调用MS Graph修改B2C用户属性

该方案唯一的限制是匿名阶段的token不由Azure签发，如果你的需求要求所有API请求都必须使用Azure签发的access token，再选择下面的自定义政策实现方案。

自定义政策简化实现步骤（全场景覆盖） #

无需使用id_token_hint透传参数，直接用B2C原生的查询参数读取能力即可大幅降低实现复杂度：

1. 在自定义政策的声明架构中新增extension_DeviceId自定义声明
2. 在用户旅程的起始编排步骤中添加规则，直接读取授权请求的deviceId查询参数，存入extension_DeviceId声明
3. 新增匿名用户创建编排步骤：当检测到请求携带extension_DeviceId且无登录上下文时，自动调用MS Graph创建访客类型的B2C用户，将extension_DeviceId存入用户自定义属性，直接签发带is_anonymous自定义声明的B2C access token返回给客户端，用户全程无感知
4. 用户发起正式注册时，先在编排步骤中校验extension_DeviceId对应的匿名用户是否存在：
   • 存在：跳过信息填写步骤，仅引导用户补充必填的注册信息（手机号/邮箱等），自动将匿名账号升级为正式账号
   • 不存在：直接走标准注册流程

注意事项 #

• 建议给匿名B2C账号设置过期标记，定期用MS Graph清理超过30天未升级为正式账号的冗余匿名账号，避免租户内用户数量超限
• 给匿名用户签发的B2C令牌添加is_anonymous自定义声明，API校验权限时可基于该声明限制匿名用户的访问范围，避免越权

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