Understanding Azure App Registrations

Microsoft offers a robust identity platform, but to facilitate authentication and authorization applications need to be registered. To that end, within Azure AD you will find the App registrations pane that offers the ability to create registrations for applications and assign permissions accordingly.

When you create an application, you establish a trust relationship between the defined application and the Microsoft identity platform. Make note that the trust is only unidirectional, in that the application trusts Microsoft but not vice versa. You can control the following aspects of Azure Apps.

  • Supported Account Types – Whether your application is used by users in a given organizational directory or if you allow personal Microsoft accounts to be used as well.
  • Redirect Settings – If the app needs to have the access token returned to a specific URI to process the next step of authentication and authorization.
  • Certificates and Secrets – Used to verify that the application connecting to the Azure Identity platform is allowed to do so.
  • Permissions

Creating a New Azure App Registration

After logging into the Azure Portal, navigate to Azure AD and App registrations as seen in the screenshot shown below.

Click on Register an Application to start the process of provisioning a new Azure App. You will be presented with a few options that need to be filled out depending on how your application works. Commonly in development, you will use a local address to test the authentication before publishing a proper endpoint. This can be changed later.

After creation, you can see that we have a new Azure App registration that has 1 web URI and the next steps would be to properly configure certificates/secrets, API permissions, Branding, and Ownership.

Configuring an Azure App Registration

Once the app has been registered with Azure AD, we can start to configure the registration accordingly. Many of the initial registration settings are located in the Authentication pane.

Platform Configurations

This is where you can configure one or more redirect URI’s depending on the platform in use. Azure app registration offers the following platforms:

  • Web
  • Single-page application
  • iOS/macOS
  • Android
  • Mobile and desktop applications

Depending on the application used, you may have to use a different platform as they support different ways to integrate with Azure AD.

This would also be a good time to talk about the changes in how applications methods of utilizing the Azure App registration has changed. Recently, Microsoft has started to end support for Azure Active Directory (Azure AD) Authentication Library (ADAL) and Azure AD Graph API. The recommended and eventually required libraries are the Microsoft Authentication Library (MSAL) and the Microsoft Graph API. These changes are to simplify and modernize the authentication and authorization workflows that are used.

Microsoft Authentication Library (MSAL)

The Microsoft Authentication Library has replaced the prior ADAL library and has support for the following libraries and frameworks.

  • MSAL.NET
  • MSAL.js
  • MSAL for Android
  • MSAL for iOS and macOS
  • MSAL Java
  • MSAL Python

Other then general technology improvements and unification across libraries, one big difference is the use of the v2.0 endpoint for Microsoft identify platform which supports both work and personal Microsoft accounts.

Microsoft Graph API

The Microsoft Graph API has replaced the Azure AD Graph API. Though both of these libraries performed similar functionality, the replacement API encompasses more than just Azure AD specific functionality and works to unify Microsoft products across the entire Azure ecosystem.

Certificates and Secrets

As with any authentication process, you need a way to identify that the incoming request is from a trusted application. In the Certificates & secrets section, you will find the ability to either upload an externally generated certificate that can be used to validate the application, or you can generate a new client secret that can be passed in during the authentication process. With client secrets, you can specify a 1 year, 2 year, or unexpiring length of time that the secret is valid.

Token Configuration

When authentication has occurred, you may need to pass back additional information to the client application. This is very often the case in SAML, for example, as you would send back an email account. In the Optional claims section, define either a single optional claim such as SAML with an email claim or a group claim that is defined for all accounts using a given method.

API Permissions

Arguably the most important section, this is where you will define the configured permissions that allow an account to read or write data depending on the allowed authorizations. By default, a given application will have the [User.Read] permissions from the Microsoft Graph API.

This is the bare minimum permission needed to authenticate and return given profile information. If you choose to Add a permission you will be presented with a screen that shows all of the many different API’s that can be queried based on successful authentication.

You might notice that there is a button for Grant admin consent for domain. This option exists so that an individual user is not granting consent for each API consumed. An organization can grant consent across the entire tenant for the application to act on behalf of any user in the tenant. This means that if the consent is granted by the admin a user will not see a consent page for the application.

Expose an API

Finally, you can individually create process flows for specific permissions that encompass such features as who can consent and to what API. You will be required to set an Application ID URI which is a prefix used to identify the API to use. This must be unique to your application and can be set to something readable for easier use.

Conclusion

Azure App registrations are an easy and powerful way to configure authentication and authorization workflows for a variety of different client types. Everything from Android to a SAML application can be configured to use an app registration. With the additional ability to restrict APIs and protected endpoints, you can quickly create a registration that just allows the permissions and abilities that your organization defines as needed!