Azure AD B2C本地账户场景下AAD技术身份的定义时机咨询

1. 纯本地账户场景下，策略内的独立AAD身份源配置是否为强制必需 #

纯本地账户使用场景下，策略中专门用于对接外部AAD做联合登录的独立配置块并非强制项，只要没有逻辑引用对应配置，完全可以整段删除，且不会触发策略加载、解析的报错。
这里要先把两类容易搞混的“AAD相关内容”区分开：

• 一类是策略里单独定义的、作为平行身份提供商存在的AAD联合登录配置，包括对应的技术定义块、Claims转换逻辑、用户旅程分支，这部分是完全可选、可自由裁剪的内容
• 另一类是Azure AD B2C平台底层内置的、负责存储本地账户用户数据、签发令牌、校验用户密码的基础目录能力，这部分是平台托管的底层逻辑，根本不需要用户在策略里手写配置，自然也不存在“删除后影响本地账户运行”的问题。很多人踩的坑就是把这部分底层能力和策略里可裁剪的联合登录配置块搞混了。

2. 完全省略独立AAD身份源配置后，会缺失的具体能力 #

裁剪掉这部分配置后，受影响的功能全是和AAD联合登录强绑定的，不会波及本地账户核心流程：

• 直接失去所有基于AAD的联合登录入口：用户无法使用工作/学校AAD账号、多租户AAD账号完成B2C应用的登录授权，所有登录路径仅能保留本地账户（邮箱/用户名/手机号+密码）的注册、登录、密码找回、邮箱验证流程
• 连带缺失原本绑定AAD身份源的专属流程分支：比如针对AAD联合用户的强制合规校验、自定义属性回填、MFA触发规则等专门面向外部AAD用户的逻辑
• 完全不影响本地账户的核心功能：包括本地账户的自定义属性配置、自定义UI页面调整、令牌签发规则、密码复杂度校验、多因素认证配置等和本地账户相关的能力，和有没有那部分AAD联合配置没有任何依赖关系。

3. 纯本地账户场景下，官方示例仍默认携带AAD配置的原因 #

• 这份基线策略的定位是覆盖所有身份场景的通用基础模板，不是专门给纯本地账户场景做的精简版本。模板本身的设计思路就是让不管用纯本地、纯社交、混合身份源的开发者，都能基于这份基线做裁剪，不用从零搭建基础策略结构
• 这些默认内置的AAD配置块是默认非激活状态：只要开发者在自己的用户旅程编排步骤里没有把AAD身份源加入登录选项序列，这部分配置就只是存储在文件里的静态代码，不会在实际流程中被触发，用户访问登录页时也根本看不到这些没有被编排启用的身份源入口
• 这种设计也能降低后续扩展成本：如果官方初始模板里删掉了所有非本地账户的配置，开发者后续如果需要增加AAD联合登录能力，就得从零复制对应的技术定义、Claims转换逻辑，反而提高了入门门槛。把通用配置默认放在基线文件里，开发者后续只要在自己的自定义用户旅程里增加对应的编排步骤，就能快速启用对应能力，不用反复抄公共配置。

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