Application identities in Azure Active Directory

Application identities in Azure Active Directory

Microsoft offers a robust identity platform in the form of Azure Active Directory. Azure Active Directory (aka Azure AD) manages identities for your Azure tenant. Along with user identities, Azure AD also centralizes application identities. In my experience, these application identities are mainly used to keep data interchanges between applications or microservices secure. However, with its own vocabulary, such as “Managed Identity”, “App Registration”, “Enterprise Application” and “Service Principal”, the landscape lacks clarity for a good number of developers. In this article, I offer a brief overview of these different concepts.

Authentication and permissions

As mentioned in the introduction, application identities are used to keep communications between applications or services secure. Security conceptually separates authentication from permission. Azure AD, through its application identities, is able to cover both aspects.

App Registration

The very first thing to remember about an app registration is that it is globally unique. An app registration is the unique representation of an application’s identity across the whole planet. In addition, it offers various functionalities:

• Checking which type of account is accessing the app (work, school or personal account)
• Checking which tenant is permitted to use the app (local tenant or multi-tenant)
• Handling redirection to web applications (redirect URI) during authentication
• Managing certificates and secrets
• Exposing APIs
• Managing and setting permissions

An app registration is essential whenever you want to make your exchanges with the outside world secure. For example, if you expose APIs for partners, you will need at least two app registrations:

• 1 app registration to represent the APIs
• 1 app registration for each client using the API

App registrations mean you can meet the needs of different OAuth flows (e.g. client credentials or authorization code). Do note, however, that you have to manage secret expiration using your own resources. This can swiftly become tedious if you plan to make widespread use of OAuth for exchanges between your components.

Entreprise Application (EA) and Service Principal (SP)

Unlike app registration and its idea of a global identity, an enterprise application is a local identity. It is set only for your tenant. There is no technical difference between a service principal and an enterprise application, only a difference in connotation:
Consequently, customarily, an enterprise application means the local representation (or instantiation) of an application in your tenant. For example, for each app registration that you have instantiated, one enterprise application exists in your tenant. Likewise, when you add an external application (e.g. Facebook or Netflix) to your tenant, you are in fact making a local instantiation of the identity in your tenant.

Managed identities

A managed identity is an identity that is managed by Azure. It is an enterprise application identity, with the particular feature that it is associated with an Azure service (Logic Apps, Data Factory, Azure Function, etc.). Managed identities are a response to two main issues:

• Renewing secrets: handled by the platform, and completely transparent for us. In addition, as far as I know, you cannot retrieve a managed identity’s secret.
• Storing the original secret: to understand this point, imagine you need to store sensitive data (such as a password) for later use. You’ll probably use an Azure Key Vault to protect such data. At the time when you need to read the password, you will have to supply a client/secret to authenticate yourself with the Azure Key Vault service. But where can you store the secret that gives you access to the Key Vault? It’s the serpent eating its own tail, an infinite loop. This is where managed identities become vital. You don’t need to store the secret because it is handled by the platform.

It should be noted that there are two types of managed identity: System Assigned or User Assigned. The first is generated by the Azure platform and assigned to a service. The second is generated by a user, then associated with one or more Azure services.