使用OAuth2无法验证微软个人账号的问题求助

• 现有OAuth2应用可正常验证M365标准用户，但outlook.com个人用户无法完成验证
• 已做修改：
  • 登录URL改为 https://login.microsoftonline.com/consumers/oauth2/v2.0/authorize?client_id=...（M365用户使用common）
  • Azure AD应用清单修改了两个属性：

    "accessTokenAcceptedVersion": 2,
    "signInAudience": "AzureADandPersonalMicrosoftAccount",
    

• 当前现象：
  • 可进入微软登录界面并完成权限确认
  • 确认后触发错误：Sorry, but we're having trouble signing you in，具体错误码为 AADSTS90023 Microsoft account logins are not supported
  • 同时收到微软邮件提示「New App(s) have access to your data」

1. 确认应用注册的账户类型设置
   登录Azure AD门户，找到目标应用注册，进入「概述」页面，检查「支持的账户类型」是否设置为「任何组织目录中的账户和个人Microsoft账户（例如Skype、Xbox、Outlook.com）」。手动修改清单可能导致界面配置未同步，直接通过可视化界面选择该选项并保存。

2. 统一使用common作为授权端点的租户ID
   无需针对M365用户和个人用户切换不同的租户ID，common端点同时支持Azure AD账户和个人Microsoft账户。将授权URL统一修改为：

   https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=...
   

   单独使用consumers端点时，若应用配置的是双账户类型，反而容易因端点与账户类型不匹配触发AADSTS90023错误。

3. 校验API权限配置
   进入应用注册的「API权限」页面，确认添加的是Microsoft Graph v2.0版本的委托权限，且权限需同时兼容工作/学校账户和个人账户（例如User.Read这类通用权限）。避免使用仅支持单一账户类型的旧版权限。

4. 检查重定向URI的一致性
   确保Azure AD应用注册「身份验证」页面中配置的重定向URI，与应用代码中使用的完全一致（包括协议、域名、路径、端口）。个人账户登录对重定向URI的校验更为严格，任何细微差异都可能导致登录失败。

5. 清除缓存后重新测试
   清除应用本地的token缓存、会话数据等，再用outlook.com用户重新发起登录流程，避免旧配置残留干扰结果。

AADSTS90023错误的核心是请求的授权端点与应用支持的账户类型不匹配。虽然手动修改了清单的signInAudience属性，但可能存在配置未同步的情况，通过Azure AD门户的可视化界面确认设置，能避免手动修改清单带来的遗漏问题。

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