Spring Boot集成Azure AD 已授予API管理员同意 为何普通用户登录仍需授权

核对授权请求的实际携带Scope #

不要仅凭组件源码推断自动携带的权限列表，直接通过浏览器开发者工具抓取登录跳转时Azure授权端点的完整URL参数，重点校验scope参数的实际值：

• 授权码模式下的正常用户登录流，仅应携带openid、profile、offline_access、https://graph.microsoft.com/User.Read这类标记为“终端用户可自行同意”的低风险scope
• 如果发现scope参数中混入了https://graph.microsoft.com/GroupMember.Read.All、https://graph.microsoft.com/Directory.Read.All这类默认需要管理员同意的高权限委托scope，甚至带入了应用程序权限（非委托权限）的scope值，就会触发Azure的同意拦截逻辑。
• 这一情况完全匹配你遇到的“管理员账号可正常登录、普通员工账号弹出需管理员同意”的现象：当当前登录用户属于全局管理员/应用管理员角色时，Azure会自动跳过同意检查环节，即使scope列表里包含未授权的高权限值也能正常完成流程；普通用户则会严格按照租户同意策略校验，只要存在未被全租户覆盖的高权限scope就会直接弹出拦截提示。

校验门户授权配置与实际请求Scope的匹配性 #

• 实际排查中非常常见的错配场景：你在Azure AD门户为应用授予的API权限条目，和Starter实际请求的scope值不属于同一个权限条目。比如你在门户给应用授予了新版Microsoft Graph的委托版Directory.Read.All权限，但Starter因版本老旧实际请求的是旧版Azure Active Directory Graph的scope，这种错配下哪怕你在门户点了全租户授予同意，Azure也识别不到对应scope已经被授权。
• 需特别注意：如果你在门户给应用添加的是应用程序权限（非委托权限），这类权限仅能用于客户端凭据流（服务到服务的无用户场景调用），完全不兼容带用户的授权码登录流。哪怕完成了全租户同意，只要登录请求的scope列表里带入了这类应用权限值，就会直接触发需要管理员同意的拦截。

排查Starter版本的已知兼容问题 #

• azure-spring-boot-starter-active-directory 3.5.0之前的旧版本存在固定逻辑Bug：只要配置了azure.activedirectory.user-group.allowed-groups参数，就会自动在授权请求中强制拼接GroupMember.Read.All高权限scope，没有提供关闭该行为的配置项。
• 遇到这类问题时可调整实现逻辑：不再通过Starter主动拉取用户组成员信息做鉴权，而是在Azure AD应用的令牌配置中，把用户所属的安全组信息直接注入ID令牌的claim中，这样就不需要额外申请高权限的Graph scope，普通用户登录时仅需基础的openid类scope即可完成流程。

校验租户全局同意策略配置 #

• 检查Azure AD租户的企业应用用户设置：如果租户开启了“阻止用户同意访问公司数据的应用”策略，且存在部分scope未被全租户同意覆盖，普通用户访问时会被强制拦截要求管理员授权，而管理员账号因为自身角色权限可以绕过该策略校验。

内容的提问来源于stack exchange，提问作者Yves V.