microsoft social sign-in Azure

Azure Application registrations, Enterprise Apps, and managed identities

This post has been lurking in my drafts for almost two years now, and after a recent discussion with colleagues, it was about time I finish it.
Weekly I get questions about Azure AD application registrations and Enterprise Applications. And since you found this post, you are probably looking for a few answers yourself.

Over the years I have done a lot of work that requires playing around with authentication in Azure. Especially the case I had with the secure application model and Microsoft CSP gave me some good insight into this space. In general, I have limited knowledge of Oauth2, etc. And most of my work in this space has been related to integration with Azure Management APIs

The purpose of this post is to demystify everything around managed identities (MSI), Azure application registrations, and Enterprise Apps. Although Microsoft has this well documented, the context can be somewhat vague. Especially for new developers and IT Pros integrating with the Azure Control plane.

Azure Application registrations

Microsoft has a very robust identity platform in Azure AD. And by creating an application registration you can use this platform to authorize and authenticate various and multiple clients (Mobile, web apps, etc).

When creating an application registration you establish a trust relationship between the Microsofts identity platform and your custom application, meaning you trust Microsoft, but Microsoft does not trust your application in the same way.

You can create single-tenant, multi-tenant, and Microsoft (liveid) based app registrations or a combination of them. But the application definition is only tied to its home directory.

Azure ad application registration portal
  • Single-tenant configuration
    • Only principals in the “home” tenant can authenticate.
  • Multi-tenant application registrations
    • Allows users and applications in other Azure AD tenants to access your app.
  • Personal Microsoft accounts
    • Here you can allow Microsoft Live ID accounts to access.
Kahoot sign-in with microsoft google and apple

Enterprise applications – service principals

App registrations are not very functional on their own. Where App registrations is you custom application definition. Enterprise application is the application identity within your directory (Azure AD). The service principal (enterprise app) can only be assigned access to the directory it exists, and act as an instance of the application.

Relationship between app registrations and enterprise applications.

Enterprise applications (the service principal) have a reference to its Application registration. In most cases, you have one app registration and the service principal (enterprise application) in the same tenant.
When the application is accessible by multiple tenants, all tenants will have one enterprise application. However, the application registration itself will be in its “home” tenant

This can be confusing. But if you look in the enterprise application blade you can find applications from other app vendors being used by you or other users in your directory.

In short: Azure application registrations are the global representation of your custom application, and Enterprise Application is the local representation of the same application, bound to your tenant.

See this post on how to create Application registrations using PowerShell.

Conditional Access

Conditional Access is where you use signals to identify if a user can access your application or not. You then use these signals in an “if-this-then-that” format to decide whether the user can access your application.

Conceptual Conditional Access process flow
Image from Microsoft Docs

Conditional access is widely used for accessing cloud resources like the Azure Portal or Office 365. However, you can also use the service for your in-house developed applications as well.

Managed identities

Another player in the mix often causing confusion for developers and administrators is Managed Identities. When released, we used the name Managed Service Identities, in short MSI. But recently Microsoft renamed this service to Managed Identities.

Managed Identities is used to assign an identity (service principal) to an Azure resource. You can use this service principle to access other resources, leveraging the built-in authentication and authorization mechanisms you find in Azure.

Managed identities can access other Azure resources or custom applications.

Previously, when we did not have managed identities, we created an application registration for the resource. Using a secret or certificate to authenticate with Azure. This created a lot of overhead, as it required secret management, key rotation, etc. With managed identities, Azure takes care of this for us.

Managed Identities comes in two configurations. One fully managed and tied to a resource, or as an individual resource.

System-assigned managed identity

System-assigned is where you tie the identity to one specific resource. You configure this during resource deployment or assign an identity after it’s deployed.

The service principal created with system-assigned managed identity will follow the resource lifecycle. If you delete the resource, the identity will also be deleted.

User-assigned managed identity

User-assigned managed identities are individual resources. Multiple Azure resources can use one managed identity, or you can use multiple identities for one resource. Microsoft will still rotate keys and secrets. But with user-assigned managed identities you are in control of the service principal lifecycle and general governance.


There are a lot more to go through when talking about authentication. How to obtain Azure access tokens or how you add Azure login to your website is not covered here. However, I hope this post made the Azure application registrations, service principal, and managed identity space a bit more clear.

  • temp mail

    Hello Neat Post, I noticed a problem with your website in Internet Explorer. Could you please check this? IE remains the leading search engine, and a significant number of people may overlook your excellent writing because of this issue.

  • johnboscow

    Amazing exam practicing software and exam guide for the Azure certification exam. I am so thankful to pass4surexams for this amazing tool. Got 90% marks.

  • RunAsRadio - App registrations and undertaking apps - Firnco

    […] sooner than I knew podcast used to be a phrase. For roughly part an hour, Richard and I mentioned Azure software registrations, undertaking apps, and controlled identities. What are they, how are you able to take pleasure in them, and what are their similarities and […]

  • RunAsRadio - App registrations and enterprise apps - adatum

    […] in 2007- way before I knew podcast was a word. For about half an hour, Richard and I talked about Azure application registrations, enterprise apps, and managed identities. What are they, how can you benefit from them, and what are their similarities and differences? Not […]

  • GitHub movements federated id with Azure AD - Firnco

    […] is simply as simple as the present DevOps setup. I’m lovely aware of Azure as an id platform, particularly with app registrations and undertaking apps. So the above script used to be achieved briefly. However, It’s not that i am that aware of […]

  • Azure token from a custom app registration - adatum

    […] The reason I had it laying in drafts is that I am unsure of the supportability from Microsoft and the potential security vulnerability it may add to your services. However, keep that in mind and use the feature when needed.If you want to learn more about application registrations, enterprise apps, and managed identities i… […]

  • GitHub actions federated identity with Azure AD - adatum

    […] just as easy as the current DevOps setup. I am pretty familiar with Azure as an identity platform, especially with app registrations and enterprise apps. So the above script was done quickly. On the other hand, I am not that familiar with GitHub APIs. […]

  • GitHub movements federated identification with Azure AD - Firnco

    […] as the present DevOps setup. I’m lovely conversant in Azure as an identification platform, particularly with app registrations and undertaking apps. So the above script used to be performed briefly. However, I’m really not that conversant in […]

  • Simon

    Please clarify where you say “App registrations are not very functional on their own. Where App registrations is you custom application definition.”

    1. Martin Ehrnst

      Do you have an idea on how to clarify?

  • Automate Azure DevOps like a boss | adatum

    […] AD part, I had mostly everything in place already. Service connections for Azure AD are essentially Azure application registrations, and Azure AD groups are easily created using New-AzADGroup or Microsoft Graph API. However, my […]

Engage by commenting