邮递员:"您无权查看此目录或页面"与承载令牌

时间:2017-06-02 21:07:23

标签: azure oauth oauth-2.0 active-directory postman

我在HostGator上有一个网站,让我们说它的域名是https://example.com

我还在Azure上托管了一个应用程序,并在整个网站上启用了Active Directory身份验证(包括API组件),让我们说它的域名是https://example.azurewebsites.net < / p>

目标 - 要在https://example.com上执行PHP文件(作为CRON作业)并首先使用Azure的Active Directory对文件进行身份验证,然后通过HTTP https://example.azurewebsites.net/api/getValues调用从GET提取数据。

问题 - 显然,只是在没有持票人令牌的情况下调用API会导致401,但我仍然会获得401即使我&# 39; m传递似乎是有效的承载令牌。

这就是我的所作所为:

使用https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code -

我访问了通过Azure AD管理门户提供给我的https://login.microsoftonline.com/{{tenant_id}}/oauth2/authorize?response_type=code&client_id={{client_id}}

这返回:

https://example.com/?code={{really_long_string_of_code}}

我接受了这个really_long_string_of_code并将其作为一个名为code的正文参数通过邮递员,如下所示:

PostMan-token-retrieval

如您所见,它返回了上面看到的令牌^。

然后,我接受了此令牌并将其通过另一个Postman电话:

postman-call

但问题是,我仍然得到确切的错误消息:

  

您无权查看此目录或页面。

我觉得我已经尝试了一切。我甚至进入portal.azure并设置了#34;允许的令牌受众群体&#34;:

Azure-portal-settings

任何人都知道我可以更改任何设置以允许此类呼叫发生吗?

2 个答案:

答案 0 :(得分:5)

邪恶的信徒已经解释了由不正确的观众引起的这个问题。我想解释一下,以帮助理解这个问题。

OAuth 2.0授权框架中有两个概念客户端和资源服务器(请参阅rfc6749)。当客户端调用资源服务器时,资源服务器将验证请求中传递的令牌。例如,它将验证签名,发行者,客户ID,观众等。

  

客户端:         代表受保护的资源请求的应用程序         资源所有者及其授权。 “客户”一词的确如此         并不意味着任何特定的实施特征(例如,         应用程序是在服务器,桌面还是其他服务器上执行         设备)。

     

资源服务器:         托管受保护资源的服务器,能够接受         并使用访问令牌响应受保护的资源请求。

在您的方案中,您获得了Azure AD Graph(https://graph.windows.net)的access_token。但是,您在门户网站配置的受众与access_token中的aud声明不匹配。要解决此问题,我们可以将在Azure AD注册的应用程序用作客户端和资源。如果是这样,我们需要使用应用程序ID 而不是应用程序ID URI 来获取访问令牌。并将此值配置为Azure门户上的允许的令牌听众

或者我们可以在Azure AD中注册两个应用程序来分别代表客户端应用和资源应用。并使用客户端应用程序获取资源应用程序的令牌。如果是这样,resource的值应该是资源应用的App ID URI,我们还需要在Azure门户上将其配置为允许的令牌听众

答案 1 :(得分:3)

允许令牌受众中删除尾随斜杠,例如:

https://example.com
http://example.com

..或者是另一种方式..嗯..

401 Unauthorized当一切看起来都正确时,通常会在观众中显示落后的斜线。有时你需要一个,有时你不需要。它应该与您或您的中间件在应用程序代码中定义为有效受众的任何内容相匹配。您还可以使用应用程序GUID(应用程序ID)作为受众。

此外,您似乎graph.windows.netresource,这是故意的吗? 你应该https://www.xxxx.com。受众群体必须与您的API网址相符。

这对我来说并不是认证machine2machine调用的正确方法。您应该只使用open that token and check the contents或者只是在标头中通过HTTPS发送硬编码密码(是的,就像承载令牌一样,但没有信任链)。在API端,将其存储在应用程序设置中,并从关联的环境变量中获取代码。在调用应用程序代码中使用相同的应用程序设置机制。

您可以使用每X天更改应用程序设置的功能应用程序来轮换此密码(PowerShell功能应用程序具有可用的资源管理cmdlet,因此您可以使用SPN登录(Add-AzureRmAccount)然后调用{{ 3}})。

或者,您可以将密钥存储在Azure Key Vault中,虽然这是一项出色的服务,但它可以为您的用例提供过度工程。