Business Central SaaS应用REST调用因Scope异常被拒，凭证验证失败

核心原因：令牌受众不匹配导致认证失败 #

你碰到的The credentials provided are incorrect错误，再结合令牌里莫名出现的Financials.ReadWrite.All，基本可以确定是请求令牌时指定的资源（Audience）不对——拿到的是旧版Dynamics Financials API的令牌，不是Business Central（BC）的，所以BC的API根本不认这个凭证。

具体排查和修复步骤： #

• 补全Postman OAuth配置里的Resource字段
  很多人只填Scope，漏掉了这个关键项。在Postman的OAuth 2.0设置里，必须明确把Resource（部分版本叫Audience）设为https://api.businesscentral.dynamics.com。如果没填或者填成了旧的https://financials.dynamics.com，Azure AD会返回对应旧API的令牌，自然过不了BC的认证。
• 确认应用注册的API权限加对了对象
  登录Azure AD应用注册后台，进到「API权限」页面：
  1. 先删掉所有和Dynamics 365 Financials相关的权限；
  2. 重新添加Microsoft Dynamics 365 Business Central的权限：
     • 用授权码流（需要用户登录）的话，加委托权限user_impersonation；
     • 用客户端凭据流（无用户交互）的话，加应用权限（比如Financials.ReadWrite.All），而且一定要点「授予管理员同意」，不然权限根本不会生效。
• 验证令牌的受众字段
  拿到新令牌后，用JWT解析工具查看内容，重点看aud字段：
  • 正确值应该是https://api.businesscentral.dynamics.com；
  • 如果显示的是https://financials.dynamics.com，说明Resource字段还是没配置对，改完重新获取令牌。
• 规范Scope的写法
  不同授权流程的Scope格式要对应：
  • 授权码流：用https://api.businesscentral.dynamics.com/user_impersonation；
  • 客户端凭据流：必须用https://api.businesscentral.dynamics.com/.default，因为应用权限需要通过.default来触发获取。

额外提醒 #

如果之前加过错误的权限，就算删掉了，Postman可能还缓存着旧令牌，记得点「Clear Tokens」清空后，重新拿新令牌再测试。

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