Azure AD B2C登录流API连接器对接外部数据库认证实现方法

你查到的关于API连接器的特性完全准确：API连接器根本无法实现绕过Azure AD B2C内置身份存储、直接对接外部遗留库完成登录凭据校验的需求，别在这个方向浪费时间。

• 触发节点不对：登录流里的API连接器，只能在两个节点触发：一是用户完成B2C内置的账号密码校验之后，二是B2C准备发放令牌之前。这两个节点你拿不到用户输入的明文密码，也没法在B2C校验凭据之前介入流程，根本没机会对接你本地的SQL Server做密码核验。
• 设计定位不对：API连接器从一开始就不是用来替换身份源的，它的原生场景是注册时校验邀请码/手机号合规性、登录时判断用户风险等级做拦截、补充自定义用户属性这类增强逻辑，碰不到核心的密码校验环节。

你的核心需求是新旧系统并行，用户用原有账号密码既能登本地老系统，也能登走Azure AD B2C的云应用，下面三个方案都是官方支持的生产可用方案，按适配度排序：

方案1：自定义策略（IEF）+ REST技术档案对接本地库（最匹配需求） #

这是最贴合你“不预迁移全量用户、登录时直接校验本地库凭据”需求的方案：

• 实现逻辑：不用提前把所有存量用户导入B2C，通过B2C的自定义身份体验框架配置REST类型的技术档案，用户在B2C登录页输入账号密码提交后，策略会直接把用户输入的凭据传给你自己部署的校验API，这个API通过混合连接/VPN打通和你本地on-prem SQL Server的网络，按照原有系统的密码校验逻辑（比如和库里存的加盐哈希做比对）完成身份核验，校验通过就直接给用户发B2C令牌。
• 配套优化：你可以在这个流程里加即时迁移（JIT）逻辑，用户第一次通过B2C校验成功后，自动把用户的账号信息、密码哈希同步写入B2C内置目录，后续用户再登录就可以直接走B2C内置校验，不用再调用本地API，等所有活跃用户都完成自动迁移，就可以平滑下线本地身份校验逻辑，完成全量割接，全程用户无感知。

方案2：批量预迁移+密码哈希同步 #

如果你能从本地SQL Server导出全量用户的账号标识、加盐密码哈希值、哈希算法规则，可以直接用B2C的批量导入接口把存量用户数据提前导入内置目录，配置密码哈希适配规则。用户第一次在B2C登录输入原密码时，B2C会自动完成哈希算法的适配转换，后续就直接走内置校验。并行阶段你只要保证新用户注册、用户改密码这类操作同时双写到本地SQL和B2C目录，就能保证两边登录体验一致，适合割接周期在3个月以内、可以拿到密码哈希规则的场景。

方案3：联合身份对接 #

如果你的遗留业务系统本身已经有支持SAML/OIDC协议的身份组件，可以直接把这个本地身份源配置成B2C的联合身份提供商。用户在B2C登录页选择“原有账号登录”时，会跳转到你本地系统的登录页完成凭据校验，校验通过后返回B2C发放令牌。这个方案完全不需要改动原有密码存储逻辑，但是登录流程有跳转，用户体验稍差，适合没法拿到密码哈希规则、也不想开发校验API的场景。

• 绝对不要硬套API连接器做登录校验：就算你把API连接器挂在登录流的最前置节点，也拿不到用户输入的密码，只能拿到B2C从内置目录读出来的用户属性，强行用会出现“只要账号在B2C存在，输任意密码都能通过校验”的严重安全漏洞。
• 并行阶段一定要做数据一致性兜底：不管选哪个方案，只要新旧系统同时运行，就要保证新增账号、修改密码、账号冻结/注销这类操作同时同步到两边的身份存储，避免出现用户在本地改了密码之后登不上云应用，或者在云应用注册的新账号登不上老系统的问题。

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