Microsoft OAuth2.0 admin_consent API返回AADSTS90027错误无法获取令牌求解

你遇到的AADSTS90027报错属于微软身份平台策略升级触发的链路拦截，并非应用侧配置变更引发的故障：

• 当前使用的https://login.microsoftonline.com/common/adminconsent是v1协议栈下的管理员同意端点，早期common租户域的路由逻辑较为宽松，即便请求被分流到MSA（个人微软账号）租户域，也不会直接阻断流程
• 如果应用注册时勾选了支持个人微软账号登录，发往common域的请求会被自动路由到MSA租户侧，而v1协议从设计层面就不支持从MSA租户签发令牌、完成授权同意流程。近期微软上线跨协议硬校验规则后，这类不匹配的请求会在跳转登录页之前直接被拦截，抛出你看到的invalid_request类错误
• 此前功能一直正常运行，是因为早期宽松的路由规则没有触发这个拦截逻辑，属于微软侧策略更新带来的兼容性问题，并非你此前的流程实现存在缺陷

可直接落地的修复方案 #

• 替换为v2协议对应的管理员同意端点，完全匹配报错提示的协议要求：将原有端点替换为https://login.microsoftonline.com/common/oauth2/v2.0/adminconsent，该端点原生支持MSA租户的授权流程，不会触发跨协议拦截
• 替换端点后需对齐v2协议的参数规范：
  • 确保请求携带与应用注册信息完全匹配的client_id
  • 携带和应用注册重定向URI列表完全一致的redirect_uri，作为管理员完成授权后的跳转地址
  • 按需补充scope参数，指定需要申请的Graph接口权限范围
  • 保留原有的state参数，用于CSRF防护校验
• 如果业务场景仅需要支持企业工作/学校账号的服务端授权，不需要兼容个人微软账号，可直接将common租户域替换为organizations域的对应端点https://login.microsoftonline.com/organizations/adminconsent，从路由层面让请求不会进入MSA租户域，彻底规避该报错
• 补充排查项：替换端点后若仍出现同类报错，检查应用注册的“支持的账户类型”配置，只要选项中包含个人微软账号的支持范围，就必须全流程适配v2协议，所有v1协议端点均与MSA租户不兼容

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