使用AcquireTokenOnBehalfOf获取令牌时遇AADSTS70000错误排查

针对你遇到的AADSTS70000错误，结合On-Behalf-Of（OBO）流程的特性，以下是几个关键排查方向：

• 确认上游令牌的权限类型
  OBO流程依赖上游（客户端→中间层）令牌中的委派权限（对应JWT中的scp声明），如果上游令牌只有应用权限（roles声明），是无法兑换下游服务令牌的。用jwt.ms解析middleTierServiceAccessToken，检查scp字段是否存在且包含有效权限值，同时确保aud字段指向中间层服务的Client ID/应用ID URI。

• 检查下游服务的权限同意状态
  你已经将中间层服务添加为下游服务的授权客户端，但还要确认：

  1. 下游服务的该权限是委派权限（应用权限无法通过OBO流程使用）
  2. 中间层服务对下游服务的权限已完成同意流程——如果是需要管理员许可的权限，必须由租户管理员完成同意；如果是用户可同意的权限，需确保兑换令牌时的用户已授权过。

• 验证目标scope的准确性
  再核对一次api://xxxx-xxxx-xxxx-xxxx/Downstreamservice.ReadWrite：

  • xxxx-xxxx-xxxx-xxxx必须是下游服务的Client ID或应用ID URI
  • Downstreamservice.ReadWrite必须是下游服务在Azure AD中定义的委派权限的“值”（注意不是显示名称，部分服务的权限值可能和显示名称有差异）

• 检查中间层服务的API权限配置
  中间层服务本身需要被授予下游服务的委派权限。登录Azure AD，找到中间层服务的应用注册，在“API权限”中添加下游服务的对应权限，并完成同意操作（管理员同意或用户同意）。

• 代码细节排查

  • 确认redirectUri与中间层服务应用注册中配置的重定向URI一致（虽然OBO流程不强制使用，但配置不匹配可能引发权限验证问题）
  • 检查客户端密钥是否有效（未过期、未被吊销），可以尝试重新生成密钥替换现有值

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