POSTMAN: “You do not have permission to view this directory or page” with Bearer Token

Question

I\'ve got a website hosted on HostGator, let\'s say it\'s domain is https://example.com.

I also have an application hosted on Azure, with Active Direc

Answer 1

Remove the trailing slash from Allowed Token Audiences, e.g.:

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

..or was is the other way around.. hmm..

401 Unauthorized when everything looks right is usually a trailing slash in the audience. Sometimes you need one, sometimes you don't. It should match whatever you or your middleware define as valid audience in the app code. You can also use the app GUID (Application ID) as audience.

Also, you seem to have graph.windows.net as resource, is that intentional? You should really open that token and check the contents. The audience must match your API's URL.

This to me doesn't feel like the right way to authenticate machine2machine calls. You should probably just use TLS mutual authentication or simply send a hard coded secret over HTTPS in a header (yes, just like a Bearer token, but without the trust chain). On the API side, store it in App Settings and pick it up in your code from the associated environment variable. Use the same App Settings mechanism in the calling app code.

You could rotate this secret using a Function App that changes the App Setting every X days (PowerShell Function Apps have the Resource Management cmdlets available so you could use an SPN to login (Add-AzureRmAccount) and then call Set-AzureRmWebApp -AppSettings [...]).

Alternatively, you can store the secret in Azure Key Vault, and while a great service it borders on overengineering for your use case.

Answer 2

The evilSnobu have already explained this issue which caused by incorrect audience. I want to explain it more general to help understand this issue.

There are two concepts client and resource server in the OAuth 2.0 Authorization Framework(refer rfc6749). When the client calls the resource server, the resource server will verify the token passed in the request. For example, it will verify the signature, issuer, client id, audience etc.

client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

In your scenario, you were acquire the access_token for the Azure AD Graph(https://graph.windows.net). However, the audience you config at the portal doesn't match the aud claim in the access_token. To fix the issue, we can use the app registered at Azure AD as both client and resource. If that, we need to acquire the access token using the Application ID instead of App ID URI. And config this value as the ALLOWED TOKEN AUDIENCES on the Azure portal.

Or we can just to register two apps in Azure AD to represent the client app and resource app separately. And using the client app to acquire the token for the resource app. If this, the value of resource should the App ID URI of resource app and we also need to config it as the ALLOWED TOKEN AUDIENCES on the Azure portal.