Introduction
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.
Protocol Flow
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!
Granting Rights
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.
Testing
Now let’s test! Do a post towards the following URI ;
https://login.microsoftonline.com/<tenant id>/oauth2/token
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.
Common Issue
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.
Closing Thoughts
- 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!
This.post.was.really helpful.Do.you.hav idea how.to.trigger the oms queries in OMS(log analytics) in azure portal using dotnet application .
https://dev.loganalytics.io/ This will help… 😉
Thank you kvaes for your help.
i have already gone through above link but oms log analytics portal have been migrated to azure portal recently so the above mentioned link haven’t helped me.Unfortunately Microsoft guys haven’t released the latest help documents. so facing difficult at this stage.
Do you have any idea from where we can get API calls for Azure resources?
In the above tutorial you are using https://manage.azure.com(old portal)but now we are using https://portal.azure .com(new portal).so all the materials available on internet regarding Azure API are related to old portal but no updated information related to new portal is not available.
Kindly help me in this regard.