In this post, we will discuss how you can make your web or client application connect to your APIs that have been secured with Azure Active Directory.

The APIs could be one you have created, or other enterprise APIs installed in your Azure tenant. This makes it possible to expose various APIs in your tenant to a client application.

Overview of the process

To allow you client, web or client-web application (hereafter client application) to access the API, your tenant should have APIs secured with AAD. The API could be one developed in-house.

We first have to create an application object to represent our client application. Depending on which type of application (web, mobile or desktop), we will configure additional settings for that specific platform. Remember, we can configure multiple platform per application. We then either add a certificate or create a client secret that the client application can use to authenticate. Finally, we grant the application object permissions to access the web APIs.

I will discuss and show how we can implement it under the following steps:

  • Create an application object
  • Configure platform settings for your application
  • Configure advanced settings for your application
  • Add credentials to your application
  • Add permissions to access web APIs

Create an application object

Application objects can be created from the App Registrations blade of the Azure Active Directory service from the Azure portal.

Configure platform settings for your application

Depending on the platform or device this application is targeting, additional configuration may be required such as redirect URIs, specific authentication settings, or fields specific to the platform.

Web Applications

For web appliction platform, you can configure

  • Redirect URIs. The URIs that will be that will be the destinations when returning authentication responses (tokens) after successfully authenticating users. Also referred as reply URLs.
  • Logout URL. This is where we send a request to have the application clear the user’s session data. This is required for single sign-out to work correctly.
  • For single-page apps, you can enable Implicit grant and select the tokens that you’d like the authorization endpoint to issue.

Android Applications

iOS or macOS Applications

Desktop and Mobile Applications

Configure advanced settings for your application

The following settings are available:

  • Default client type. Determines the application’s client type in the use of flows that do not use redirect URIs.​
  • For desktop apps that acquire tokens by using Integrated Windows Authentication, device code flow, or username/password in the Default client type section, set the Treat application as public client setting to Yes.
  • Supported account types. The Supported account types specify who can use the application or access the API.

Add credentials to your application

To add a credential to your application, either add a certificate or create a client secret. To add a certificate:

  1. From the app Overview page, select the Certificates & secrets section.
  2. Select Upload certificate.
  3. Select the file you’d like to upload. It must be one of the following file types: .cer, .pem, .crt.
  4. Select Add.

To add a client secret:

  1. From the app Overview page, select the Certificates & secrets section.
  2. Select New client secret.
  3. Add a description for your client secret.
  4. Select a duration.
  5. Select Add.

Note:
After you save the configuration changes, the right-most column will contain the client secret value. Be sure to copy the value for use in your client application code as it’s not accessible once you leave this page.

Add permissions to access web APIs

From the app Overview page, select API permissions. Under Configured permissions, select Add a permission. Once you’ve selected the APIs, you’ll see the Request API Permissions page.

A list of all API applications secured with your AD will show. If the API exposes both delegated and application permissions, select which type of permission your application needs.

When Delegated permissions are used by apps, either the user or an administrator consents to the permissions that the app requests, and the app is delegated permission to act as the signed-in user when making calls to the target resource.

Application permissions are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Application permissions can only be consented by an administrator.