无需迁移用户即可使用Azure Active Directory B2C的方案咨询

这是个非常典型的遗留身份系统整合场景，刚好可以利用Azure AD B2C的扩展能力来解决——完全不用迁移ERP里的用户数据，同时能解决API耦合、合规管控的问题。下面是具体的落地思路：

1. 用自定义策略将现有认证API集成到B2C作为身份提供者 #

Azure AD B2C的**自定义策略（Custom Policies）**是核心，它允许你扩展默认的认证流程，添加自定义的REST API调用步骤。具体操作逻辑是：

• 用户在新接入系统的登录界面输入凭证，请求转发到Azure AD B2C
• B2C在认证流程中调用你的现有认证API，把用户输入的用户名/密码（或其他凭证）传递给API做验证
• 只要现有API返回验证成功的响应（比如包含用户唯一标识），B2C就会继续流程，颁发自己的JWT令牌给接入系统；如果验证失败，就返回错误给用户

这样做的好处是：

• 完全不用修改闭源ERP的认证流程，所有验证逻辑还是依赖你现有的API
• 新接入系统只需要和B2C对接，不用直接耦合到原认证API，后续接入效率会大幅提升

关键配置要点 #

• 先在B2C的自定义策略中定义REST API技术配置，指定API的URL、请求方法、认证方式（比如用API密钥或客户端证书确保B2C和原API通信的安全）
• 在用户认证旅程（User Journey）中添加一个验证步骤，将用户输入的凭证映射为API请求参数，调用原认证API并处理返回结果

2. 以B2C为统一身份层，管控所有接入系统的认证 #

为了避免其他部门自行创建不合规的认证机制，你需要把B2C设为唯一的入口：

• 所有新接入的系统必须在Azure AD B2C中完成应用注册，获取专属的客户端ID和密钥，只能通过B2C发起认证请求
• 禁止任何系统直接调用原认证API，通过权限管控和网络策略（比如防火墙规则）限制原API的访问范围，只允许B2C调用
• 你还可以在B2C层统一补充安全规则，比如强制多因素认证（MFA）、密码复杂度要求，即使原ERP/认证API不支持这些功能，也能在B2C层面实现，提升整体安全性

3. 创建影子用户，避免全量用户数据迁移 #

因为用户数据都存在闭源ERP里，你不需要把数据迁移到B2C目录中，只需要在用户首次通过B2C认证后，创建一个影子用户（Shadow User）：

• 影子用户只存储用户的核心标识（比如ERP里的用户ID、邮箱），不复制全量用户属性
• 后续如果接入系统需要获取用户的额外属性，B2C可以在认证流程中调用ERP的查询API（如果允许的话），实时获取数据并添加到令牌中，或者让系统自行调用ERP API（用B2C令牌做授权）

这种方式既保持了用户数据的唯一数据源（ERP），又能让B2C识别用户身份，正常颁发令牌。

4. 逐步解耦现有系统的API依赖 #

对于已经和原认证API耦合的现有系统，可以分阶段迁移：

• 第一步：在现有业务API前添加一层API网关，要求调用方必须携带Azure AD B2C颁发的JWT令牌，验证通过后才转发请求到业务API
• 第二步：修改现有系统的认证逻辑，从直接调用原认证API改为通过B2C获取令牌，再用令牌访问业务API
• 这样逐步完成系统迁移，既不影响现有业务运行，又能彻底解决耦合问题

注意事项 #

• 确保现有认证API支持被B2C调用：需要有标准化的接口（比如POST请求接收凭证，返回明确的成功/失败状态和用户标识）
• 自定义策略的开发需要一定的Azure AD B2C知识，但微软提供了大量模板可以基于修改，不用从零编写
• 要关注认证流程的性能：优化原认证API的响应时间，或者在B2C中配置合适的缓存策略，减少重复调用
• 通信安全：B2C和原API之间必须用HTTPS加密，同时用API密钥或客户端证书做双向认证，防止请求被篡改或伪造

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