Let’s understand Azure AD application and it’s permissions – Part 2

Namaste and welcome back to my blog post.

This post is in continuation with the previous post where I explained about the Azure AD application and the permissions. In this post, I am going to cover the remaining part of the webinar which I took last week.

We are going to explore: –

How you can authenticate a user using AD application? How OAuth2.0 plays a role here.

How permission and consent that we set works here?

How you can access delegated permission without making the user login every time?

Earlier I planned to cover all these topics but recently my very good friend Omkar Khair took an awesome webinar on OAuth. He has explained how we OAuth the way we do. So, rather than repeating the same information here. I will suggest you visit his blog post (link will be published by next week) to dig deep about OAuth 2.0.

Meanwhile, I will cover the above topics in brief: –

Let’s try to understand how you can authenticate a user using the AD application.

To authenticate a user with Azure AD application OAuth flow is used. We will be exploring OAuth 2.0 authorization code grant flow in this blog post. You can find the most authentic information about OAuth protocol here. 

I have broken down the OAuth 2.0 auth code grant flow in simple terms that I understand. There are multiple ways by which OAuth 2.0 can be executed like by using implicit grant flow, auth code grant, on-behalf of flow and few other which you can find here.

To simply put the authentication code grant flow, I have divided it into 3 parts: –

1. Requesting Authorization code
2. Fetching access token
3. Calling the API

To request an authorization code, you will need: –

1. Tenant Id = Can be fetched from the active directory or the app itself
2. Client Id = Can be fetched from the application detail present in the Azure portal.
3. Redirect_uri = This you set in the AD application that you have created.
4. response_type = code (since we are following auth code grant request)
5. scope = This if you keep default will include the permission set on the application or it can be comma-separated permission

Once we have the required information we will be following this flow: –

The detail about this process is mentioned in the Microsoft document itself so I am not going to repeat the same information here but what I wanted you to understand that the process can be considered as 3 step process: –

1. Request Authorization code – User will hit the login button which will take the user to a site with the URL which will look like https://login.microsoftonline.com/<tenant>/oauth/v2.0/authorize?<some set of parameters>. After the user enters their credentials, the user will be redirected back to the redirect_uri specified while raising the request with the value of the code.
2. Fetch the access token – With the code received in the previous step, you can raise a request to fetch the access token as specified here. With the success of this request, you will receive an access token.
3. Call the API – With the access token received in the last step, you can call the API for which you wanted to authenticate. You can call the graph API or any other API for which you had specified the scope by passing this access token in the header. Reference.

This OAuth in itself is a very interesting topic but I am not spending a lot of time here to explain this because my friend Omkar Khair will be publishing an article by next week which I will link here as soon as it is available.

With the above request, you can authenticate the user using OAuth 2.0.

Now, the next question is how do the permission and consent work here. To answer it in simple term – When a request to fetch the auth code was raised then it checks if the user who is authenticating has consented or not. If the user has not consented for the permission that is specified and if the admin consent was not granted for those permissions then User will be shown a consent screen.

Once the user gives his/her consent then that is registered in the application present in the user’s tenant directory.

Now, let’s talk about how delegated permissions can be accessed without user login.

The simple answer is no, without showing the user interactive login an app cannot access the delegated permissions. At least once the app has to show the interactive login.

Wait, we just said at least once. What does this mean? Does this mean that we can access delegated permissions via an app if we have authenticated the user once with interactive login? The answer is YES!

To make this possible “offline_access” scope is also passed in the request. When we pass “offlince_access” in the scope when we request for auth code, we will be authenticating as usual and you won’t see any difference.

But, when you will be sending the next request to fetch the access token, you will get “refresh_token” as well in the response. This refresh_token is valid for 90 days. “access_token” that is fetched is valid for 1 hour by default. So, what does this mean?

This means that you can use refresh_token to get a new access token. Consider, you got “code” from the first request (offline_access was also passed in the scope), after which you raised a request to fetch access token. Now, this access token is valid for 1 hour.

Now, if you come tomorrow and want to access on behalf of that user without making the user log in again then you will be using refresh_token to fetch new access_token. When you will receive the response, you will receive access_token as well as new refresh_token. You can store this refresh_token at your end and use this again to request for new access_token next time.

This way you will be able to use the user’s context of delegated permission till the time the refresh_token is valid. A freshly issued refresh token is valid for 90 days even if it is inactive.