Azure AD B2C自定义策略：ConvertStringToPhoneNumberClaim验证失效

当你将LocalAccountSignUpWithLogonEmail的验证技术配置从TrustFrameworkBase.xml移至TrustFrameworkExtensions.xml后手机号验证失效，大概率是以下几个核心原因导致的：

1. 技术配置未正确覆盖Base策略 #

Azure AD B2C自定义策略中，Extensions策略的技术配置需要明确覆盖Base中的同名配置才能生效。如果Extensions里的LocalAccountSignUpWithLogonEmail技术配置存在定义缺陷，会导致Base中的旧配置仍在执行，而旧配置可能没有包含手机号验证逻辑。

• 检查Extensions中的<ClaimsProvider>是否完整包含LocalAccountSignUpWithLogonEmail的技术配置，且配置的Id与Base中完全一致；
• 确认用户旅程（User Journey）中引用的技术配置ID是LocalAccountSignUpWithLogonEmail，且没有被其他步骤覆盖。

2. 声明转换的调用时机或参数错误 #

ConvertStringToPhoneNumberClaim需要在用户提交表单后、创建用户前被触发，且参数传递必须准确：

• 检查验证技术配置中是否在<InputClaimsTransformations>或<OutputClaimsTransformations>里正确调用了该声明转换，例如：

  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="ConvertStringToPhoneNumberClaim" />
  </InputClaimsTransformations>
  

• 确认输入声明phoneNumberString（用户输入的手机号）和countryCode（用户选择的国家代码）的名称与实际表单提交的声明完全匹配，避免拼写错误；
• 检查声明转换的输出是否映射到了内置的mobile声明，确保后续存储用户数据时使用的是经过验证的合规号码。

3. 用户旅程中验证步骤的执行顺序错误 #

验证逻辑必须在创建用户的步骤之前执行，否则无效号码会被先存入租户，验证失效：

• 查看用户旅程的<OrchestrationStep>，确保LocalAccountSignUpWithLogonEmail的验证步骤（ClaimsExchange）顺序在AAD-UserWriteUsingLogonEmail（创建用户的技术配置）之前；
• 例如：验证步骤的Order设为3，创建用户步骤的Order设为4，确保验证失败时直接终止流程，不会进入用户创建环节。

4. 验证错误的返回机制未开启 #

如果技术配置中允许生成无效数据，即使声明转换失败也不会报错：

• 检查验证技术配置的<Metadata>部分，确保没有设置AllowGenerationOfClaimsWithInvalidData为true，默认值为false，此时转换失败会返回错误阻止注册：

  <Metadata>
    <Item Key="AllowGenerationOfClaimsWithInvalidData">false</Item>
  </Metadata>
  

排查步骤建议 #

1. 先确认Extensions中的LocalAccountSignUpWithLogonEmail技术配置是否被正确引用，可通过策略调试工具查看执行的技术配置路径；
2. 检查声明转换的输入输出声明是否与实际流程中的声明一致，调试时查看声明的传递路径；
3. 验证用户旅程中步骤的执行顺序，确保验证在用户创建前完成；
4. 测试时使用策略调试工具跟踪每一步的声明变化，确认ConvertStringToPhoneNumberClaim是否被触发，以及转换后的结果是否正确。

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