Azure App Service服务间调用Bearer令牌认证失败问题

我来帮你梳理下这个场景下的常见排查步骤——这种多层应用的配置我碰到过不少，几个容易忽略的细节往往是问题根源：

1. 先检查令牌本身的核心字段是否合规 #

拿你获取到的Bearer令牌，用本地的JWT解析工具（比如离线解码库）拆开看几个关键内容：

• aud（受众）：必须和目标API的应用ID URI完全匹配，绝对不能填目标API的客户端ID！很多人在这里踩坑，EasyAuth会直接拒绝受众不匹配的令牌。
• iss（颁发者）：要和目标API的EasyAuth配置的AD租户一致，比如格式是https://login.microsoftonline.com/{你的租户ID}/v2.0或者v1版本的格式，确保颁发令牌的租户和API绑定的租户是同一个。
• exp（过期时间）：确认令牌没过期，这个是最基础的检查项。
• roles或scp声明：如果你的API设置了权限控制，要确保令牌里包含对应的应用角色（服务主体流）或委托范围（代表流），否则会返回403权限不足。

2. 验证目标API的EasyAuth配置是否正确 #

登录Azure门户，进入目标API的App Service，打开「身份验证」面板逐一检查：

• 确认「允许未经身份验证的请求」是关闭状态（你之前设置的是强制跳转到AD登录，这个是对的）。
• 检查绑定的Azure AD应用注册是不是目标API对应的那个，重点确认应用ID URI填写正确——这个是aud字段的唯一合法值。
• 如果是v1端点的应用注册，要在「公开API」里确认已经添加了正确的权限范围，并且调用方（其他API或客户端）已经获得了这些范围的授权。
• 如果用的是服务主体流，要确认调用方的服务主体（应用注册）已经被分配了目标API的应用角色，并且完成了管理员同意。

3. 排查ADAL调用流程的正确性 #

你提到用了服务主体流和代表流，分两种场景逐一核对：

代表流（OBO）场景 #

如果是前端UI先登录，然后上游API调用下游API时用OBO流换取令牌：

• 确认OBO请求里的assertion参数是上游API收到的用户令牌，OBO流只能用用户令牌来换取下游API的访问令牌，应用令牌是不行的。
• 检查ADAL代码里的resource参数，必须填写下游API的应用ID URI，而不是客户端ID。
• 确保上游API的应用注册里已经添加了下游API的委托权限，并且完成了管理员同意——OBO流必须要有管理员同意才能生效。

服务主体流（Client Credentials）场景 #

如果是API之间直接用服务主体身份调用：

• 确认调用方的应用注册已经被授予目标API的应用权限（不是委托权限），并且完成了管理员同意。
• 检查ADAL获取令牌时的resource参数，同样必须是目标API的应用ID URI。
• 确认服务主体的证书或客户端密钥是有效的，没有过期或被吊销。

4. 查看App Service的认证日志找具体错误 #

开启目标API的App Service日志，这是定位问题最直接的方式：

• 打开「应用服务日志」，然后在「日志流」里实时查看认证失败的详细错误信息。EasyAuth会返回非常具体的提示，比如“Invalid audience”、“Missing required claim”、“Token signature invalid”等，这些信息能直接帮你锁定问题。
• 也可以查看「诊断日志」里的Auth相关日志，里面有完整的认证过程记录，能帮你排查令牌传递、验证的全流程。

5. 确认令牌的传递方式没有问题 #

• 确保服务间调用时，Bearer令牌是放在Authorization请求头里，格式严格是Bearer {你的令牌内容}——注意Bearer首字母大写，令牌前后不要有多余的空格或换行。
• 如果是上游API转发令牌给下游API，不要对令牌做任何修改（比如Base64解码再重新编码），这样会破坏令牌的签名，导致验证失败。

几个最容易踩的坑 #

• 把客户端ID当成应用ID URI用：这是最常见的错误，记住EasyAuth只认应用ID URI作为令牌的受众，客户端ID完全不生效。
• 忘记给权限做管理员同意：不管是委托权限还是应用权限，只要是服务间调用，几乎都需要管理员同意才能让令牌包含对应的权限声明。
• 令牌版本和API端点不匹配：如果API的EasyAuth配置的是v2端点，但ADAL请求的是v1令牌，可能会出现声明格式不兼容的问题，导致验证失败。

如果按照上面的步骤排查后还是解决不了，可以把日志里的具体错误信息贴出来，这样能更精准地定位问题。

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