top of page
  • Writer's pictureNathan

App Registrations, Enterprise Apps, and Service Principals

Updated: Aug 27, 2022

I wouldn't be exaggerating if I said that a full length book could be written about this subject alone. There's just so much that could be talked about!

My goal of this blog post is to stay pretty high level. I'll try my best to outline the major pieces of this puzzle, and to explain what each one does.


The whole point of these 3 resources is to allow you to register your application or service with Azure AD. You are setting up a trust relationship between your app and the Microsoft identity platform. This is a one-way trust, where you app trusts the Microsoft identity platform, not the other way around.

Why would you want to register your application with Azure AD? Well, here are some of the main reasons:

  • Application authentication and authorization

  • User authentication and authorization

  • Single-sign-on

  • User provisioning and synchronization

  • Role-based access control

  • OAuth authorization services

  • Application publishing and proxy

One thing I want to make clear is that these 3 resources live at the Azure AD "tenant" level. Permissions to manage these 3 items are handled via Azure AD roles. For more about the differences between Azure AD Roles and Azure RBAC Roles, please see my article here.


App Registrations

How to access: Azure Portal > Azure Active Directory > App registrations

This is how you globally define your application. Only one global definition (App Registration) exists. This App Registration lives in your Azure AD (the “home” tenant), and it gets its own globally unique ID. Even if you allow other companies to use your application, there still exists only one App Registration, and it exists in your Azure AD tenant.

Some of the things that you can define for your Application at the App Registration level include (not an exhaustive list):

  • Setting it’s name, logo, publisher info, various URLs (homepage, terms of service, private statement)

  • Setting it’s Redirect URIs

  • Marking it as Single tenant (only available to accounts in your Azure AD) or Multitenant (available to accounts in any Azure AD)

  • Defines how tokens are issued to access the application

  • Configuring certificates & secrets

  • Configuring one or more AppRoles

  • Allowing your application to access one or more APIs

  • Allowing your application to expose its own APIs


Enterprise Apps (Service Principals)

How to access: Azure Portal > Azure Active Directory > Enterprise applications

The terms “Enterprise Apps” and “Service Principals” can be used interchangeably as they are essentially the same thing. When you go to the Enterprise applications section of the Azure Portal it will show you all of the Service Principals in your tenant (unless your Service Principal has a special “hidden” tag configured on it).

Service Principals are what define and govern how the application connects to your own Azure AD. Every Azure AD that uses your application will get its own, separate Service Principal for your application.

For a single tenant application it will look like this:

  • App Registration: 1 instance in your Azure AD

  • Enterprise App: 1 instance in your Azure AD

For a multitenant application it will look like this:

  • App Registration: 1 instance in your Azure AD

  • Enterprise App: N instances (1 instance in every Azure AD that uses your application)

Example of a multitenant application:

Some of the things you can do or define for your application at the Enterprise App level include (not an exhaustive list):

  • Your own custom Name or Logo that will take precedence over the name or logo defined at the App Registration level.

  • Assign User or Groups from your Azure AD to the AppRoles (remember, AppRoles are defined at the App Registration level)

  • Track who has consented to the permissions that the application requests

  • You can assign the Service Principal to Azure RBAC roles and therefore give it permissions to Resources in your Subscription


For the most part, App Registrations and Enterprise apps go hand in hand. When you have one, you also have the other. In fact, when you create a new App Registration via the Azure Portal, it will automatically create an Enterprise App for you as well. I do want to highlight a couple of exceptions:

  • If you use the Microsoft Graph API, then you have to create an App Registration and an Enterprise App (service principal) through two separate commands. However, the Microsoft Graph API will not let you create a Service Principal without first creating an App Registration.

  • The AzureAD module in PowerShell will still let you create an individual Service Principal that is not tied to an App Registration. This is considered legacy, and should only be used if necessary.


This is quite a huge subject and could potentially be the topic for many blog posts to come. However, I wanted to keep this post high level and I think I'll end things here.

Checkout Part 2 of this series for more on this subject. Part 2 focuses specifically on App Roles and Scopes.





bottom of page