Azure AD B2C自定义策略疑问：ClaimsProviderSelection步骤后能否使用CombinedSignInAndSignUp？

你遇到的这个报错其实是Azure AD B2C自定义策略的编排步骤规则限制导致的——系统明确要求，ClaimsProviderSelection类型的步骤之后，必须紧跟ClaimsExchange类型的步骤，而CombinedSignInAndSignUp本身是一个独立的起始步骤（它自带身份提供者选择、登录注册整合的逻辑），并不符合这个后续步骤的类型要求，所以上传时会触发验证错误。

不过别担心，我们可以换个思路实现你的需求：既保留“先选登录方式（社交/本地），点击本地按钮后展示登录+注册表单”的交互，又避开这个规则限制。具体做法是把整合登录注册的逻辑放到ClaimsExchange步骤引用的TechnicalProfile中，而不是直接用CombinedSignInAndSignUp作为步骤类型。

具体修改方案 #

1. 调整编排步骤结构：保持第一步为ClaimsProviderSelection（展示选择按钮），第二步仍用ClaimsExchange类型，只是把本地账号对应的ClaimsExchange指向一个整合了登录注册功能的TechnicalProfile。
2. 配置对应的TechnicalProfile：确保这个本地账号的TechnicalProfile支持登录和注册的切换逻辑（比如默认显示登录表单，同时提供注册入口，或者自动判断用户是否存在来展示对应表单）。

修改后的用户旅程示例代码如下：

<UserJourney Id="SignUpOrSignInCustom">
  <OrchestrationSteps>
    <!-- 步骤1：展示身份提供者选择按钮（谷歌/本地账号） -->
    <OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselections">
      <ClaimsProviderSelections>
        <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
        <ClaimsProviderSelection TargetClaimsExchangeId="LocalCombinedExchange" />
      </ClaimsProviderSelections>
    </OrchestrationStep>

    <!-- 步骤2：执行选中的身份验证流程，本地账号使用整合登录注册的TechnicalProfile -->
    <OrchestrationStep Order="2" Type="ClaimsExchange" ContentDefinitionReferenceId="api.signuporsignin">
      <ClaimsExchanges>
        <!-- 谷歌OAuth2验证流程 -->
        <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAuth2" />
        <!-- 本地账号登录+注册流程（自定义的SelfAsserted类型TechnicalProfile） -->
        <ClaimsExchange Id="LocalCombinedExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignUpOrSignIn-Email" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- 后续步骤：创建会话、颁发令牌等（保留你原有逻辑即可） -->
    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>

补充说明 #

• 你需要确保SelfAsserted-LocalAccountSignUpOrSignIn-Email这个TechnicalProfile是正确配置的：可以基于默认的SelfAsserted-LocalAccountSignin-Email进行扩展，添加注册相关的字段和验证逻辑（比如调用AAD-UserReadUsingEmailAddress检查用户是否存在，动态切换登录/注册表单）。
• 步骤2的ContentDefinitionReferenceId使用api.signuporsignin是合适的，因为这个内容定义本身就支持登录和注册界面的渲染。

这样调整后，既满足了你“先选按钮再展示本地登录注册表单”的交互需求，又符合Azure AD B2C的编排步骤规则，不会再出现上传报错的问题。

备注：内容来源于stack exchange，提问作者julianomontini