Azure AD认证获取访问令牌时遇AADSTS90008权限错误求助

这个AADSTS90008错误我之前帮不少开发者排查过，核心问题就是所需的权限没有被正确授予用户/管理员同意，结合你描述的情况——自己配置的权限没启用，反而多了个没添加的权限，咱们一步步来解决：

1. 清理异常的多余权限 #

首先登录Azure门户，找到你的应用注册：

• 进入API权限页面，仔细检查列表里的权限，把那个你没添加的多余权限删掉。
• 如果列表里没有这个多余权限，但用户同意界面还能看到，大概率是之前的同意缓存残留。这时候可以让用户自己撤销对应用的同意：用户登录Azure AD的「我的应用」，找到你的应用，点击「管理」→「撤销访问权限」；或者作为管理员，在企业应用里找到该应用，进入「用户和组」，删除相关用户的同意记录。

2. 确认所需权限的配置正确性 #

确保你添加的是正确的权限类型和范围：

• 你需要的「Sign in and read user profile」对应的是Delegated类型的User.Read权限（属于Microsoft Graph），一定要确认添加的是Delegated权限，而不是Application权限（后者是应用自身权限，不适合用户登录场景）。
• 检查每个所需权限的状态，确保它们处于「已配置」状态，如果是需要管理员同意的权限（部分高权限会要求），点击「授予管理员同意」按钮，完成全局同意。

3. 重新触发正确的用户同意流程 #

旧的同意缓存可能导致权限请求异常，我们可以强制触发新的同意界面：

• 手动构造同意请求URL，确保包含你需要的权限scope：

  https://login.microsoftonline.com/{你的租户ID}/oauth2/v2.0/authorize?client_id={你的应用ID}&response_type=code&redirect_uri={你的回调地址}&scope=openid profile User.Read&prompt=consent
  

  把占位符替换成你的实际信息，prompt=consent参数会强制弹出同意界面，让用户明确看到并同意所需的权限列表。
• 让用户访问这个URL，完成同意操作后，再测试登录流程。

4. 检查代码中的权限请求配置 #

有时候问题出在代码里的scope参数：

• 确认你的认证请求（比如OAuth2/OpenID Connect请求）中，scope参数包含了openid、profile、User.Read这些所需的权限，而不是只请求了那个多余的权限。如果scope配置错误，Azure AD会只请求错误的权限，导致所需权限未被同意。

5. 排查应用清单的残留配置 #

如果以上步骤都没用，可以检查应用的清单（Manifest）：

• 在应用注册页面点击「清单」，搜索requiredResourceAccess字段，确保里面只包含你需要的权限配置，删除任何多余的权限声明，保存后重新配置API权限。

按照这个流程走下来，应该就能解决权限同意异常的问题，让用户登录时正确授予所需的权限了。

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