Question

我跟随this guide通过Microsoft Graph进行身份验证。我能够成功完成第一个请求（对于授权代码），但是遇到了第二个请求（请求访问令牌）的问题。

第二个请求的参数（用于访问令牌）：

client_id: <my id>
client_secret: <my secret>
code: <authorization code returned from first request>
redirect_uri: http://localhost:8080/Callback
grant_type: authorization_code
scope: https://graph.microsoft.com/user.read

第二次请求出错：

{
  "error": "invalid_resource",
  "error_description": "AADSTS50001: Resource identifier is not provided.\r\nTrace ID: <my trace id>\r\nCorrelation ID: <my correlation id>\r\nTimestamp: 2017-05-03 15:25:42Z",
  "error_codes": [
    50001
  ],
  "timestamp": "2017-05-03 15:25:42Z",
  "trace_id": <my trace id>,
  "correlation_id": <my correlation id>
}

但是，如果我添加这个额外的参数，我的请求可以正常工作（返回一个承载和刷新令牌）：

resource: https://graph.microsoft.com/

我没有在文档中的任何位置看到此资源参数，除了获取访问令牌下的示例 {{ 3}}

我的问题是：

当我的请求似乎与文档匹配时，为什么会出现上述错误？
我何时需要包含资源参数？

编辑：请参阅下面Marc的回答和我的评论回复。

原来我使用了以下网址：

https://login.microsoftonline.com/common/oauth2/authorize https://login.microsoftonline.com/common/oauth2/token

当我应该使用时：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize https://login.microsoftonline.com/common/oauth2/v2.0/token

使用v2.0后，我不再需要在令牌请求中包含resource参数了。

Answer 1

看起来您提供了正确的属性，但格式不正确。要获取令牌，您需要发出POST格式，格式为application/x-www-form-urlencoded到https://login.microsoftonline.com/common/oauth2/v2.0/token。在您的示例中，您似乎将数据发送为JSON而不是x-www-form-urlencoded。

POST URL: https://login.microsoftonline.com/common/oauth2/v2.0/token
POST HEADER: Content-Type: application/x-www-form-urlencoded
POST BODY: grant_type=authorization_code&code=[AUTHORIZATION CODE]&
           client_id=[APPLICATION ID]&client_secret=[PASSWORD]
           &scope=[SCOPE]&redirect_uri=[REDIRECT URI]

几个月前我写了Microsoft v2 Endpoint Primer，这可能会帮助你完成整个过程。

Answer 2

根据https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code，

目标资源无效，因为它不存在，Azure AD无法找到它，或者配置不正确。

根据https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-scopes，

...与Azure AD集成的任何第三方资源也是如此。任何这些资源也可以定义一组权限，可用于将该资源的功能划分为更小的块。

然后

通过定义这些类型的权限，资源可以对其数据以及数据的公开方式进行细粒度控制。第三方应用可以从应用用户请求这些权限。应用用户必须先批准权限，然后才能代表用户执行操作。通过将资源的功能分块为较小的权限集，可以构建第三方应用程序以仅请求执行其功能所需的特定权限。应用程序用户可以确切地知道应用程序将如何使用他们的数据，并且他们可以更加确信应用程序没有恶意行为。

因此，回答1）我认为您只需要在应用程序的Azure AD页面中指定user.read权限。要回答2），您不会为第三方应用程序指定资源。

请求访问令牌时的资源参数？

2 个答案: