用Postman向Dataverse API发起OAuth请求遇401错误求助

一、可能遗漏的配置及修复步骤 #

以下是触发401 Unauthorized错误的常见原因及对应设置：

• 确认令牌受众与作用域
  获取Bearer令牌时，必须指定Dataverse环境专属作用域：https://{your-org-url}.crm.dynamics.com/.default，而非Graph API或通用作用域。用jwt.ms解析令牌，检查aud字段是否严格匹配你的Dataverse环境URL（例如https://contoso.crm.dynamics.com），不匹配则会被权限系统拒绝。
• 验证应用权限类型与管理员同意
  确保Azure AD应用中配置的是应用权限（Application permissions），而非委派权限（Delegated permissions）——客户端凭证流只识别应用权限。同时必须完成管理员同意（在Azure AD应用的权限页面点击「授予管理员同意」），否则配置的权限不会生效。
• 检查Dataverse应用用户的安全角色
  在Dataverse中创建的应用用户，必须分配具备足够权限的安全角色（例如「系统管理员」或包含WhoAmI权限的自定义角色）。无角色的应用用户即使持有有效令牌，也无法访问任何Dataverse端点。
• 规范请求头格式
  调用/WhoAmI端点时，请求头需包含以下字段：

  Authorization: Bearer {your-token}
  Accept: application/json
  OData-MaxVersion: 4.0
  OData-Version: 4.0
  

  缺少OData版本头也可能触发401或格式错误。

二、两个授权端点的区别 #

• 通用授权URL（https://login.microsoftonline.com/common/oauth2/v2.0/token）
  使用common租户标识符时，允许任何Azure AD租户的身份请求令牌，适配多租户应用场景。但调用Dataverse这类单租户专属服务时，可能导致令牌的租户ID（tid）或受众（aud）不匹配，引发权限验证失败。
• 带TenantID的授权URL（https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token）
  指定具体租户ID的端点，会生成绑定到该租户的令牌，确保tid字段与你的Dataverse租户完全一致，是调用Dataverse API的推荐选项。这种方式能避免跨租户权限验证问题，令牌有效性更有保障。

内容的提问来源于stack exchange，提问作者Márk Farkas