In this article we briefly explains how a Native Application client can authenticate itself against Azure AD and obtain access token in order to safely gain access to a secured Web API. Then, a very short example is given using Java and CURL.

Terminologies

First of all, we should introduce some terminologies in nutshell since most of them are being used in this article or others in the wild.

Native Client Application. This is an application which wants to impersonates a user and gain access to a secured Web API on behalf of the user. This can be an app.

Web API. Web API is the secured resource (according to OAuth 2.0) that the Native Client Application wants to have access to it.

Azure AD. This is an identity provider provided by Microsoft as a Cloud-based Active Directory. Native Client Application tries to authenticate the user using Authorization Code Grant flow of OAuth 2.0 in order to provide 2 things: Authorization code and Access token.

Authorization Code. This is a temporary intermediate code (String) generated by Azure AD for Native Client Application after user authentication (will be explained later on). Using this code, Client Application can get the access token.

Access Token. This is a JWT formatted token received back from Azure AD, so called Bearer Token. Native Client Application can pass the Bearer Token along with other data in the requests to the Secured Web API and gain access to the resources of the user on his behalf. Access Tokens are short-lived; then, they should be refreshed upon expiration/revoking using Refresh Tokens.

Refresh Token. This is a token received back from Azure AD to Native Application Client in OAuth 2.0 flow. Native Application Client can re-fetch new token from Azure AD by using them (when the existing Access Token is expired/revoked).

How it works?

We assume that Native Client Application, Web API and Azure AD are set up and configured correctly. Configurations will be explained later on. In this scenario, the client application needs to take several important steps: (1) redirecting the user to AzureAD for authentication; then, fetching the Authorization Code, (2) obtaining an Access Token for the authenticated user and (3) requesting new Access Tokens using Refresh Token whenever the Access Token is revoked or expired.

Azure AD Configurations

I assumed that you have a tenant in Azure AD and applications are ready to be created and configured.

Web API

This is our secured Web API which is going to be exposed to a Native Client Application. In application tab of your tenant, you can click on the new application. You should select a name for your application and choose the app type as WEB APPLICATION AND/OR WEB API. Then, you need to fill a Sign-on URL as well as APP ID. Depending on your Web API, these can be as follows:

Sign-on URL: http://127.0.0.1:7105
App ID URI: http://<tenanat-name>.onmicrosoft.com/<MyWebAPIName>

Now, your Web API is created and partly configured in Azure AD. For production configuration, it is advised to use TLS (https) for your sign-on URL. If you need to do more advanced configuration, you can download the Manifest file in the bottom of the page and modify it and, then, upload it back to the Azure AD.

Native Client Application

In this section, we need to create a Native Client Application in Azure AD and enable the impersonation permission against the Web API in the client configurations.

Fist of all we need to create a Native Client Application within our tenant by click on “New” button and selecting a NATIVE CLIENT APPLICATION radio button. After choosing an arbitrary name for the app, you are supposed to fill an Redirect URI to complete the creation process. When user is authenticated against Azure AD in a Microsoft login page, he will be redirected back by Microsoft to your app along with an Authorization Code and a Session State. In other words, your app should always wait for invocations triggered by Azure AD on a redirect URI (e.g. a REST API such as http://127.0.0.1:7106/api/auth/) in your native client app. Then, using the received Code, you app is able communicate with Azure AD and obtain the Access and Refresh tokens.

When your native client application is created, it’s time to change the permission in order to enable the app to access our Web API (which is created in previous section). In our client app configuration, in the section called “permissions to other applications“, click on Add Application. Then, click on all apps and search for your Web API name, and select it. Now the access permission should be given to the Web API.

In Action

In this section, we try to make this work and eventually obtain Access and Refresh tokens: once with CURL, and once with Java.

First of all, we need to forward the end user to Microsoft to get authenticated. Then, Azure AD will redirect the authenticated user back to our Client Application (i.e. to our configured redirect URI). So, the start point is to forward the end user to the following URI for authentication:

The Client ID and Redirect URI can be found in the configuration page of your native client application. By sending your users to above address, they must authenticate as follows:

According to our configuration, Microsoft will redirect the user to our provided redirect URI along with a generated Authorization code and a session State as follows (in query parameters).

From now on we have the authorization code; then, we can obtain the Access and Refresh tokens (in following sections, in 2 approach).

Using CURL

Since we have the authorization code  based on previous actions in last section, we can invoke a POST method to the token resource of the Azure AD. This can be done using CURL as follows:

Then, Azure AD replies back with:

 

Using Java and ADAL client Library

After obtaining the authorization code, there is a java library called Adal4j which facilitate the process of fetching and refreshing access tokens. First of all, you need to add the following dependency to your maven file.

You should have a resource in your REST controller for accepting the Azure AD redirects. If you remember, we have have configured a redirect URI earlier in our native client application. This is the redirect URI. End users will be redirected to this resource (in Client Application) after getting authenticated.

Using the context object you can easily refresh your tokens with your Refresh tokens. If you need to read further about OAuth 2.0 and Azure AD, you should read the following articles.

• The OAuth 2.0 Authorization Framework
• Authentication Scenarios for Azure AD
• Authorization Code Grant Flow

by