已登录状态下使用Azure AD B2C自定义密码更改策略时出现「Invalid username or password」错误的问题排查求助

我之前也碰到过类似的Azure AD B2C自定义密码更改策略的问题，结合你的描述，大概率是已登录状态下旧密码验证的数据源或者声明传递出了问题，给你几个排查方向和解决思路：

• 检查密码验证技术配置文件的数据源
  你用的是AAD-UserReadUsingObjectId还是其他读取用户数据的技术配置文件？已登录状态下，策略是依赖当前登录用户的objectId来读取数据的，但如果密码验证步骤没有正确关联到这个读取到的用户记录，就会出现验证失败。
  确认密码验证的技术配置文件（比如Login-NonInteractive）里，是否正确设置了用户匹配逻辑，确保是用当前登录用户的凭据去验证旧密码，而不是重新走一遍通用登录的用户匹配流程。

• 排查声明传递的完整性
  已登录状态下，用户的signInName或者email声明是否在密码更改流程中正确传递到了验证步骤？有时候已登录后，策略可能没有把用户的登录标识声明传递给旧密码验证环节，导致系统找不到对应的用户，从而抛出「Invalid username or password」错误。
  可以在自定义策略的<OutputClaims>和<InputClaims>节点里检查，确保在密码更改的用户旅程中，从登录状态过来时，用户的唯一标识（比如signInName）被正确传递到验证旧密码的步骤中。

• 对比正常运行的邮箱更改策略
  既然你有一个能正常运行的更改邮箱的自定义策略，把它和密码更改策略做细节对比：

  • 看看两者在已登录状态下的用户旅程起始步骤有什么不同，邮箱策略是不是正确保留了用户的身份声明？
  • 检查两个策略中读取用户数据的技术配置文件是否一致，密码更改策略是不是少了某些关键的声明读取或者输出配置？

• 启用应用程序洞察日志排查细节
  打开Azure AD B2C的应用程序洞察日志，在已登录状态下触发密码更改错误，然后查看日志里的详细错误信息：

  • 找到对应的错误事件，查看CorrelationId关联的具体错误详情，比如是用户找不到，还是密码验证时的用户标识不匹配？
  • 日志里会显示每个步骤的声明传递情况，能帮你精准定位到哪一步丢失了关键的用户信息。

• 检查用户流和自定义策略的兼容性
  你提到初始登录用的是标准signin用户流，虽然理论上自定义策略兼容用户流，但有时候用户流的声明和自定义策略的声明映射可能存在冲突：

  • 确认标准登录用户流返回的声明（比如sub、signInName）在自定义密码更改策略里是否能被正确识别和使用？
  • 尝试用自定义登录策略代替标准用户流完成登录，看看是否还会出现同样的问题，排除用户流和自定义策略的声明不兼容的可能性。

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