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.
Sources: