If you decide to host your API application in Azure, then you should consider using Azure Ad to secure your application. The advantages here are that, your Azure AD administrator can centrally manage access to all applications registered with Azure AD. Users with active accounts can seamlessly work with your applications that leverage API secured with Azure AD.

As an API developer, you don’t have to implement a security layer in your API app. If you secure your API app with Azure AD, you get the OAuth authentication out of the box. That means, you can access your API from wide range of application types.

To secure your Web API, we start by creating an application object.

Creating Application Object

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

Application ID URL, Scopes and Permissions

After creating the application object, we need to expose some permissions/scopes and roles. The Microsoft identity platform implements the OAuth 2.0 authorization protocol. Now, any web-hosted resource that integrates with the Microsoft identity platform has a resource identifier, or Application ID URI. Example, Microsoft Graph has https://graph.microsoft.com as the Application ID URI.

Any application we add to Azure AD can define a set of permissions that can be used to divide the functionality of application into smaller chunks.

As an example, Microsoft Graph has defined permissions to do the following tasks, among others:

  • Read a user’s calendar
  • Write to a user’s calendar
  • Send mail as a user

By dividing the application’s functionality into smaller permission sets, third-party apps can be built to request only the specific permissions that they need to perform their function. In OAuth 2.0, these types of permissions are called scopes. They are also often referred to as permissions.

A permission is represented in the Microsoft identity platform as a string value. Continuing with the Microsoft Graph example, the string value for each permission is:

  • Read a user’s calendar by using Calendars.Read
  • Write to a user’s calendar by using Calendars.ReadWrite
  • Send mail as a user using by Mail.Send

Microsoft identity platform supports two types of permissions: Delegated permissions and Application permissions.

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.

From the MyWebAPI overview page, select the Expose an API blade. If you have not set an Application ID URI, you will see a prompt to enter one.

Your application can control access to the web API at runtime by evaluating the scope (scp) claim(s) in the received OAuth 2.0 access token.

When the Add a scope page appears, enter your scope’s information:

The following tables explain the fields at the scope page.

Field Description
Scope name Enter a meaningful name for your scope.

For example, Employees.Read.All.
Who can consent Select whether this scope can be consented to by users, or if admin consent is required. Select Admins only for higher-privileged permissions.
Admin consent display name Enter a meaningful description for your scope, which admins will see.

For example, Read-only access to Employee records
Admin consent description Enter a meaningful description for your scope, which admins will see.

For example, Allow the application to have read-only access to all Employee data.

If users can consent to your scope, also add values for the following fields:

Field Description
User consent display name Enter a meaningful name for your scope, which users will see.

For example, Read-only access to your Employee records
User consent description Enter a meaningful description for your scope, which users will see.

For example, Allow the application to have read-only access to your Employee data.

If you are building an ASP.NET Web API, Visual Studio simplifies the process significantly. After completing the authentication setup wizard, Visual Studio adds all the necessary references and settings to your ASP.NET Web API project, including registering a new Azure AD application to secure your API.

Secure the API using Azure App Service Authentication

When deploying custom APIs to Azure App Service, you can benefit from the App Service Authentication option to secure the API with Azure AD. In the Azure portal, search for and select App Services, and then select your app.

From the left navigation, select Authentication / Authorization > On.

By default, App Service provides authentication but doesn’t restrict authorized access to your site content and APIs. You must authorize users in your app code. To restrict app access only to users authenticated by Azure Active Directory, set Action to take when request is not authenticated to Log in with Azure Active Directory. When you set this functionality, your app requires all requests to be authenticated. It also redirects all unauthenticated to Azure Active Directory for authentication.

Restricting access in this way applies to all calls to your app, which might not be desirable for apps that have a publicly available home page, as in many single-page applications. For such applications, Allow anonymous requests (no action) might be preferred, with the app manually starting login itself.

Select the Azure Active directory form the authentication providers list.

In the express configuration, you can choose which Azure AD application should be used to secure the access to the App Service hosting the API.
You can also configure app settings manually from the advanced tab if you want to use an app registration from a different Azure AD tenant.