如何将无邮箱用户迁移至Azure B2C并在首次登录时提示补充邮箱？

我之前处理过几乎一模一样的迁移场景，你之前的思路卡在了「前置检查邮箱」上，导致无邮箱用户根本没法进入流程——其实核心应该是先让用户用现有用户名完成身份验证，再在登录流程中强制引导补全邮箱，而不是把无邮箱用户挡在登录门外。下面是一套可落地的自定义策略方案：

核心流程设计 #

1. 允许用户名登录验证

   • 先在Azure B2C自定义策略中配置支持「用户名+密码」的身份验证技术配置（比如通过REST API调用你的原数据库做验证），跳过前置的邮箱检查步骤。这里要确保验证逻辑和原系统一致，比如校验用户名和密码的正确性，返回用户唯一标识（比如原数据库的用户ID）作为声明。
   • 关键是：登录步骤只负责验证用户身份，不判断是否有邮箱。

2. 登录后检查邮箱状态

   • 在用户通过身份验证后的编排步骤中，添加一个ClaimsTransformation或者调用REST API，检查当前用户的邮箱声明是否存在（或者从原数据库查询该用户是否已绑定邮箱）。
   • 配置前置条件：如果邮箱不存在，跳转到自定义的「补全邮箱并验证」步骤；如果邮箱已存在，直接进入后续的令牌发放流程。

3. 强制补全并验证邮箱

   • 创建一个自断言页面（Self-Asserted Page），专门用于收集用户的邮箱地址，并配置内置的邮箱验证逻辑（比如发送验证码到用户输入的邮箱，要求用户输入验证码完成验证）。
   • 验证通过后，调用REST API同步更新你的原数据库和Azure B2C的用户记录：把邮箱写入原数据库的用户表，同时更新Azure B2C用户的email属性（可以用Graph API或者自定义API实现）。

4. 完成登录流程

   • 邮箱更新完成后，继续执行后续的编排步骤，生成并发放包含邮箱标识的令牌，让用户正常进入系统。

自定义策略关键节点示例 #

1. 用户名验证的TechnicalProfile #

<TechnicalProfile Id="UsernamePasswordValidation">
  <DisplayName>Username Password Validation</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://your-api-domain.com/validate-username-password</Item>
    <Item Key="AuthenticationType">Basic</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" />
    <InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="userId" />
    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="userEmail" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

2. 检查邮箱的编排步骤 #

<OrchestrationStep Order="3" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>email</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="EmailCollectionExchange" TechnicalProfileReferenceId="SelfAsserted-EmailCollection" />
  </ClaimsExchanges>
</OrchestrationStep>

3. 邮箱收集与验证的TechnicalProfile #

<TechnicalProfile Id="SelfAsserted-EmailCollection">
  <DisplayName>Collect and Verify Email</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ContentDefinitionReferenceId">api.selfasserted.email</Item>
    <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">Please provide a valid email address</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="objectId" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="email" Required="true" />
    <OutputClaim ClaimTypeReferenceId="emailVerified" DefaultValue="true" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingObjectId" />
    <ValidationTechnicalProfile ReferenceId="REST-UpdateUserEmailInDB" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

注意事项 #

• 安全性保障：用户名登录必须配合密码验证，不能仅靠用户名就通过身份校验，避免非法用户冒充。
• 强制补全：确保邮箱补全步骤无法跳过，通过自定义策略的前置条件和页面配置，让用户必须完成邮箱验证才能继续。
• 数据一致性：邮箱更新后一定要同步原数据库和Azure B2C，避免后续登录出现数据不一致的问题。

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