Postman Client Credentials Flow with Azure AD protected ressource
I think the main reason is because in Postman, I can not type the resource I want to access, so the received token is not "linked" to any resource and that is why the authorization fails in the web server? Could this be the reason?
You are correct. To get the access token via client credential flow, we need to provide the resource in the request.
What did you mean that not able to type the resource? The resource parameter is a parameter we can contain it in the body and here is a figure for your reference:
And be ensure that the value of resrouce is eaque to the audience config used to protect the resource.
EDIT
I think the problem is that Azure Token server doesn't accept client credentials sent as an Authorization header. e.g.
Authorization: Basic YmE1NTZlYmItZGY2OS00NjBhLWEwMjItNTI0NWQ0MzA2N2UxOmVxVzlqaXRobXF2cVFiVWY5dmxaWnhZN2wwUzZhQ0pHSkExSGt0eUd3N0W6
but that's how Postman's "Get new access token" tool sends it. So it's isn't going to work.
If you look at Microsoft's documentation and search for "get a token" you will see it implies that client credentials should be supplied in the body.
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
This works fine but seems to contradict the Oauth 2.0 spec which says:
The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.
END EDIT
You definitely can get a bearer token back without supplying a resource.
Notice that resource isn't even spelt correctly in the postman http body of the previous answer - it's spelt as resrource which is why it's value of https://graph.microsoft.com is ignored and does not match the resource sent back in the response (00000002-0000-0000-c000-000000000000). Although funny enough they both relate to the api graph...but that's a digression.
Confusingly there are two ways of supplying client credentials to an Oauth 2.0 server and some servers don't accept both ways!
- 1 is adding a
basic authheader which is set to Base64(ClientId + ":" + ClientSecret) - 2 is adding clientId and clientSecret in the body of the request.
I guess that's the problem with Oauth 2.0 being a spec rather than a protocol... See - https://tools.ietf.org/html/rfc6749#section-2.3.1
Postman's Request Token UI (see image below) uses method 1, but Azure auth server expects method 2. I know because I ran fiddler, and could see the request postman put together.
If you manually put the client credentials in the body e.g.
grant_type=client_credentials&scope=&client_id=ba556ebb-xxxx9-460a-ax2x-5245d43067e1&client_secret=eqW9jighghghgvlZZxY7l0S6aCJGJA1HktyGw7E=
and don't use a Basic Auth http header. You can get a bearer token back even without suppyling a resource.
This works fine - but obviously that's no good for you in terms of using postman to get and store your tokens!
