Azure B2C自定义策略：验证配置文件与用户旅程复用可行性问询

完全可以复用同一用户旅程来处理你描述的三种场景，核心是通过验证配置文件的声明返回值配合用户旅程的条件分支逻辑，在原有登录流程中嵌入自动注册的分支步骤。以下是具体实现思路和要点：

核心实现逻辑 #

基于你已有的禁用注册的登录策略，在登录流程中插入两个关键步骤：

1. 调用本地DB验证配置文件，获取两个核心状态声明：
   • emailExists：标记邮箱是否存在于本地DB
   • idpMatched：标记邮箱对应的IDP是否与当前登录的IDP匹配
2. 根据这两个声明的值，通过条件分支执行不同流程：
   • 若emailExists=false：直接终止旅程，返回登录失败提示
   • 若emailExists=true且idpMatched=true：跳过注册步骤，继续执行原有登录流程
   • 若emailExists=true且idpMatched=false：触发自动注册流程，完成后继续登录旅程

具体配置调整 #

1. 完善验证配置文件的返回声明 #

确保你的本地DB验证技术配置文件返回所需状态声明：

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="emailExists" PartnerClaimType="email_exists"/>
  <OutputClaim ClaimTypeReferenceId="idpMatched" PartnerClaimType="idp_matched"/>
</OutputClaims>

其中email_exists和idp_matched是你的DB API返回的布尔值字段。

2. 在用户旅程中添加条件分支步骤 #

在原有IDP登录步骤之后，插入验证和分支逻辑：

<!-- 步骤1：调用本地DB验证邮箱与IDP关联关系 -->
<OrchestrationStep Order="3" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="ValidateEmailAndIdp" TechnicalProfileReferenceId="LocalDbValidationProfile"/>
  </ClaimsExchanges>
</OrchestrationStep>

<!-- 步骤2：根据验证结果分支处理 -->
<OrchestrationStep Order="4" Type="ClaimsExchange">
  <Preconditions>
    <!-- 邮箱不存在：直接返回登录失败 -->
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>emailExists</Value>
      <Value>false</Value>
      <Action>SendClaims</Action>
    </Precondition>
    <!-- IDP已匹配：跳过注册流程，直接进入后续登录步骤 -->
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>idpMatched</Value>
      <Value>true</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <!-- 执行自动注册：先在B2C创建本地用户，再更新本地DB的IDP关联记录 -->
  <ClaimsExchanges>
    <ClaimsExchange Id="AutoSignUpUser" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail"/>
    <ClaimsExchange Id="UpdateDbIdpLink" TechnicalProfileReferenceId="LocalDbUpdateIdpProfile"/>
  </ClaimsExchanges>
</OrchestrationStep>

3. 配置自动注册的技术配置文件 #

修改LocalAccountSignUpWithLogonEmail，使其使用IDP返回的声明自动填充用户信息，无需用户手动输入：

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="email" DefaultValue="{OIDC:Email}" />
    <InputClaim ClaimTypeReferenceId="givenName" DefaultValue="{OIDC:GivenName}" />
    <InputClaim ClaimTypeReferenceId="surname" DefaultValue="{OIDC:Surname}" />
  </InputClaims>
  <Metadata>
    <Item Key="EnforceEmailVerification">false</Item>
    <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
  </Metadata>
</TechnicalProfile>

4. 配置本地DB更新的技术配置文件 #

创建LocalDbUpdateIdpProfile，调用你的DB API将当前登录的IDP信息与邮箱关联：

<TechnicalProfile Id="LocalDbUpdateIdpProfile">
  <DisplayName>Update Local DB with IDP Info</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-db-api-endpoint.com/update-idp-link</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="email" />
    <InputClaim ClaimTypeReferenceId="idp" PartnerClaimType="identity_provider" />
  </InputClaims>
</TechnicalProfile>

关键注意事项 #

• 幂等性保障：确保自动注册和DB更新的API具备幂等性，避免因重试导致重复创建用户或重复写入数据
• 异常处理：在技术配置文件中添加错误处理逻辑，当API调用失败时返回明确的错误信息
• 流程测试：分别测试三种场景（邮箱不存在、IDP匹配、首次登录需自动注册），验证分支逻辑的正确性

内容的提问来源于stack exchange，提问作者José Pelayo