使用Microsoft身份提供商登录失败，其他提供商可正常使用

我来梳理下你这个Azure AD B2C + Angular SPA场景的情况和后续集成的关键要点哈：

你通过Azure门户的「立即运行」功能已经确认了策略的核心流程完全正常：

• Google账号登录、邮箱注册登录都能成功触发重定向到指定的应用回调页面，这说明策略本身的身份提供商配置、重定向URI绑定都是没问题的。
• 三个身份提供商（Google、Microsoft、本地邮箱账户）的配置均已生效，没有出现身份验证流程中断的情况，这为后续Angular SPA的集成打下了稳定的基础。

接下来把这套策略集成到Angular2 SPA里，需要重点注意这几个细节：

• 推荐使用@azure/msal-angular库来实现身份验证，配置时要确保租户ID、策略名称、客户端ID和Azure门户里的信息完全一致，尤其是策略名称要填完整的策略ID（比如B2C_1_signupsignin1这种格式）。
• 重定向URI要双向匹配：既要在Azure门户的应用注册里设置为Angular应用的实际回调路径（比如http://localhost:4200/auth-callback），也要在MSAL的配置里同步这个路径，并且要选择「单页应用」类型的重定向URI。
• 用MSAL的MsalGuard配置路由守卫，保护那些需要登录才能访问的页面；同时通过MsalService监听登录成功的事件，获取用户的ID Token和访问令牌，用来做后续的业务逻辑验证。
• 提前把Angular应用的域名加到Azure AD B2C的CORS允许列表里，避免后续调用接口时出现跨域拦截的问题。

如果后续集成时遇到问题，可以先从这几个方向排查：

• 要是Google/Microsoft登录没响应，去对应的第三方控制台（比如Google Cloud Console）检查回调URI是否配置正确，这个URI需要指向Azure AD B2C的端点，格式大概是https://<你的租户名>.b2clogin.com/<你的租户名>.onmicrosoft.com/<策略名>/oauth2/authresp。
• 如果邮箱注册后拿不到用户信息，检查策略里是否配置了需要返回的用户属性（比如displayName、email），同时在MSAL的范围配置里也要包含这些属性对应的权限。

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