For today’s post, we’re going to do a REST call towards an Azure API. For this we’re going to create a “Servce Principal” and afterwards use the credentials from this object to get an access token (via the Oauth2 Client Credentials Grant) for our API.
What’s the flow going to be?
- The application does a clients_credential call. Here it’ll provide ;
- it’s application id as a client_id
- it’s secret as the client_secret
- choose “clients_credentials” as the grant_type
- set the “resource” to “https://management.azure.com”
- AAD will return an access token
- You can now call the API adding an additional header ;
- Header Name = Authorization
- Header Value = “Bearer *accesstoken*”
- The API will return a response
(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service )
Now let’s see how that would look in reality?
Creating your Service Principal
First we’ll start off by creating our service principal. Look towards a service principal as a “daemon/system user”. For a more appropriate wording, check an earlier post… Anyhow, let’s go to “App Registrations” in our Azure Active Directory.
And create a new one…
Nothing fancy here…
Copy the “Application ID”, and save it. This is going to be your “client_id”.
And create a “Key”, which will be your “client_secret”. So please note that down as well!
Now that we’ve created the service principal. Grant it the appropriate rights it needs for its job ;
In this case, I’ve added my SP with way too much rights… 😉
Finding the REST API
The tip of the day here is to navigate to https://resources.azure.com . This is the Azure Resource Explorer, which provides you with a detailed (and up-to-date!) view of the APIs for YOUR resources.
So for this Demo, I’ve navigated to a resources (B2C Directory) and copied the URL to get the object information.
Now let’s test! Do a post towards the following URI ;
And add the following keys to the body (as mentioned at the start of the post ) ;
The response will include an access token. Copy this value… If you are very curious, you can even decrypt this via the following website ; http://jwt.ms/
For now, we’ll be using this access token as the authorization header for our REST API call. For this, add a header called “Authorization” and put “Bearer ” in front of your access token for the value.
And BOOOM! That’s it… 😉
A common issue is to forget setting the “resource”. By setting this value, you are defining the scope of your access token.
If you fail to set the resource, then Azure will indicate that the scope is not correct and that the access token isn’t relevant for its APIs. Thus… you won’t be able to access the services.
- A client_credentials flow should only be done if the secrets can be safeguarded. Do not use them in an SPA (Single Page Application) or in an app that is on an untrusted device.
- Do not forget to set your resource, or you won’t be able to access the Azure REST APIs.
- The examples above were done by using Postman. Your biggest friend when working with API Development! 😉
- Oauth is THE standard in terms of cloud / identity. I concur that it’s rough to start with… Though do each flow via direct calls (without using an SDK) to get it “into your fingers”. Once you know what is going on, please only use an SDK, as with security… the slightest slip-up will haunt you!