Outlook Add-In经后端API调用MS Graph遇AADSTS65001权限错误求助

核心问题 #

AADSTS65001错误的本质是：你的后端API应用未获得用户或管理员对目标Microsoft Graph权限的同意，即便你在Azure AD中配置了权限，也必须完成对应的同意流程才能让OBO令牌转换生效。

具体解决方案 #

1. 核对Azure AD应用权限配置 #

• 后端API应用（注意不是Outlook Add-In的注册应用）必须添加Delegated类型的Graph权限（比如你需要的Mail.Read），并且完成同意操作：
  • 企业环境建议由管理员执行全局管理员同意，避免每个用户重复操作；
  • 测试环境可使用个人账号完成用户同意，前提是租户允许用户自行同意应用权限。
• 区分开Add-In应用和后端API应用的权限：Add-In的权限用于获取用户令牌，后端API的权限才是OBO流程中调用Graph的依据，两者不能混用。

2. 修正OBO请求的Scope参数格式 #

你当前请求中的Scope用+分隔权限，应该改成空格分隔的标准格式：

{ "scope", "https://graph.microsoft.com/Mail.Read offline_access" },

虽然+在Form编码中会被转义为空格，但直接使用空格更规范，能避免潜在的解析异常。

3. 验证Add-In获取的用户令牌权限 #

用jwt.ms解码Add-In拿到的用户令牌，检查scp字段是否包含Mail.Read相关权限。如果没有，需要：

• 在Add-In的Azure注册应用中添加对应的Delegated Graph权限；
• 确保用户已经完成对Add-In应用的权限同意（可通过重新触发Add-In的SSO流程完成）。

4. 补充交互式同意的 fallback 逻辑 #

当OBO请求返回AADSTS65001时，说明用户未同意权限，需在Add-In中触发交互式同意：

• 在handleSSOErrors函数中捕获该错误，调用Office.context.ui.displayDialogAsync打开后端的权限同意页面，或直接引导用户完成Graph授权流程；
• 同意完成后，重新获取用户令牌再传递给后端重试。

5. 检查OBO请求参数的正确性 #

逐一确认以下参数：

• grant_type：urn:ietf:params:oauth:grant-type:jwt-bearer是正确的，无需修改；
• assertion：确保传递的是Add-In获取到的完整用户令牌（你用的userAccessInfo.Token.RawData是正确的）；
• tenantId：如果是多租户应用，建议用common替代固定租户ID，除非你明确只针对单个租户；
• client_id和client_secret：必须是后端API应用的ID和密钥，不要误用Add-In的应用信息。

6. 手动测试权限同意流程 #

构造授权URL，手动完成同意操作后再测试OBO流程：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=你的后端API应用ID&response_type=code&redirect_uri=你的后端API回调URI&scope=https://graph.microsoft.com/Mail.Read offline_access&prompt=consent

用浏览器打开该URL，登录目标用户并完成权限同意，之后再发起OBO请求验证是否成功。

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