邮件客户端凭据流与Azure AD保护的资源

Question

我目前正在使用这个例子

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#daemon-or-server-application-to-web-api

在Azure AD中使用OAuth检查客户端凭据流.从理论上讲,这个例子可行.客户端应用程序成功与服务器App通信,首先从Azure AD令牌URL获取OAuth令牌.没有问题.但是,我正在尝试使用Postman检查客户端凭据流,但我无法使其工作.

在邮递员中,我应该提供访问令牌URL,客户端ID和客户端密钥,授权类型设置为客户端凭据.使用与https://github.com/Azure-Samples/active-directory-dotnet-daemon中的Microsoft示例提供的示例中相同的参数,在尝试访问Web服务时收到401响应.我认为主要原因是因为在邮递员中,我无法输入我想要访问的资源,因此收到的令牌不会"链接"到任何资源,这就是为什么授权在Web服务器中失败的原因？这可能是原因吗？如果这是原因,那么我应该在服务器中做什么,因为,不知何故,似乎Postman的要求应该是客户端凭据流中的有效要求(我的意思是,根据OAuth2客户端凭据,不应该给出任何资源)流,对吗？

这是从Microsoft示例下载的示例中的Starup类的代码

    // For more information on configuring authentication, please visit http://go.microsoft.com/fwlink/?LinkId=301864
    public void ConfigureAuth(IAppBuilder app)
    {
        app.UseWindowsAzureActiveDirectoryBearerAuthentication(
            new WindowsAzureActiveDirectoryBearerAuthenticationOptions
            {
                Audience = ConfigurationManager.AppSettings["ida:Audience"],
                Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
            });
    }

ConfigurationManager.AppSettings ["ida:Tenant"]是我的Azure AD帐户,而 ConfigurationManager.AppSettings ["ida:Audience"]是我需要访问的受保护资源.这两个值都是必需的.如果我没有提供受众,我在.net web api初始化中收到错误.

Answer 1

编辑

我认为问题在于 Azure 令牌服务器不接受作为授权标头发送的客户端凭据。例如

Authorization: Basic YmE1NTZlYmItZGY2OS00NjBhLWEwMjItNTI0NWQ0MzA2N2UxOmVxVzlqaXRobXF2cVFiVWY5dmxaWnhZN2wwUzZhQ0pHSkExSGt0eUd3N0W6

但这就是邮递员的“获取新访问令牌”工具发送它的方式。所以这是行不通的。

如果您查看Microsoft 的文档并搜索“获取令牌”，您将看到它暗示应在正文中提供客户端凭据。

POST /common/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=535fb089-9ff3-47b6-9bfb-4f1264799865&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=qWgdYAmab0YSkuL1qKv5bPX&grant_type=client_credentials

这工作正常，但似乎与Oauth 2.0 规范相矛盾，该规范规定：

授权服务器必须支持 HTTP Basic 身份验证方案，用于对获得客户端密码的客户端进行身份验证。

结束编辑

您绝对可以在不提供资源的情况下取回不记名令牌。

请注意，resource在上一个答案的邮递员http正文中甚至没有正确拼写 - 它被拼写为resrourcewhich，这就是为什么它的值被忽略并且与响应中发回的https://graph.microsoft.com值不匹配的原因。虽然很有趣，但它们都与 api 图相关……但这是题外话。resource(00000002-0000-0000-c000-000000000000)

令人困惑的是，有两种向 Oauth 2.0 服务器提供客户端凭据的方法，而某些服务器不接受这两种方法！

• 1 添加一个basic auth设置为 Base64(ClientId + ":" + ClientSecret) 的标头
• 2 是在请求​​正文中添加 clientId 和 clientSecret。

我想这就是 Oauth 2.0 作为规范而不是协议的问题...请参阅 - https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1

Postman 的请求令牌 UI（见下图）使用方法 1，但 Azure 身份验证服务器需要方法 2。我知道，因为我运行了 fiddler，并且可以看到请求 postman 放在一起。

如果您手动将客户端凭据放入正文中，例如

grant_type=client_credentials&scope=&client_id=ba556ebb-xxxx9-460a-ax2x-5245d43067e1&client_secret=eqW9jighghghgvlZZxY7l0S6aCJGJA1HktyGw7E=

并且不要使用Basic Authhttp 标头。即使不提供资源，您也可以取回不记名令牌。

这工作得很好 - 但显然这对你使用邮递员获取和存储你的令牌没有好处！