Next.js中Azure委托(OBO)流获取API令牌失败问题排查

核心错误原因 #

AADSTS50013错误的本质是Azure AD无法验证你发起OBO请求时提交的用户访问令牌的签名，或者该令牌的签名密钥不在Azure AD的信任范围内。

具体排查与修复步骤 #

1. 验证用户令牌的签名密钥匹配性 #

• 用jwt.io解码Next.js获取的Microsoft Graph令牌，查看x5t字段值是否和错误提示中的指纹xxxx完全一致
• 登录Azure门户，进入Next.js对应的应用注册：
  • 检查证书和密码选项卡中的证书，确保存在指纹匹配的有效证书（未过期、私钥未丢失）
  • 若你用的是客户端机密而非证书，OBO流默认要求使用证书签名的断言，此时需要切换为证书认证方式

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

• 确认assertion参数传入的是完整的用户访问令牌（不是ID令牌，ID令牌无法用于OBO流）
• scope参数必须是你的.NET 6 API的应用ID URI加上对应权限后缀，例如api://{your-api-client-id}/access_as_user
• 确保请求中的client_id和凭据（证书/客户端机密）是Next.js应用注册的有效信息，且该应用已被授予调用.NET API的委托权限（需完成管理员同意的权限要提前审批）

3. 核对.NET API的应用注册配置 #

• 进入.NET API的应用注册，在公开API选项卡中，确认已将Next.js应用添加为已授权的客户端应用
• 检查API的权限配置，确保Next.js应用已被分配所需的委托权限

4. 理解刷新令牌方式成功的原因 #

刷新令牌方式能绕过OBO流的签名验证步骤，直接用用户刷新令牌向Azure AD请求API令牌，但这种方式需要存储刷新令牌，安全性不如OBO流。解决签名验证问题后，OBO流就能正常工作，实现更优雅的认证链路。

代码实现的常见坑点 #

在Next.js的api/auth/[...nextauth]/route.ts中处理OBO请求时：

• 不要对用户令牌做任何修改（比如错误编码、截断），直接原封不动作为assertion传入
• 使用证书签名时，确保代码加载的证书和Azure AD应用注册中的证书完全一致（包括私钥的正确加载）

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