It’s one of the confusing parts of Azure Active Directory (Azure AD) and something that many find difficult to understand properly. Often the terms are used interchangeably which only exacerbates the confusion. So what is the difference between an app registration, enterprise application and service principal in Azure AD?
Let’s start with the easy part - an enterprise application is a service principal. When you go to Azure AD in the Azure Portal and open up the list of Enterprise applications you’re looking at a list of service principals in your tenant.
I believe most of the confusion with enterprise apps and service principals comes from the term “enterprise apps” actually referring to applications published in the Azure AD gallery that you can use within your organization. This gallery is presented if you click the new application button in the enterprise applications blade of Azure AD. You can also create custom enterprise apps from this blade.
When you create a new enterprise application, either from the gallery or a custom app or service principal, you’ll find that an app registration is also created. So what’s this app registration?
An app registration represents a globally unique instance of your application, allowing you to integrate your app with Azure AD and use its features. You manage things like secrets and certificates, API permissions, token claims, branding and more with your app registration.
This app registration requires a service principal to represent it within an Azure AD tenant so that the application can access resources secured by Azure AD. The service principal is where access policies and permissions are assigned for the application. The app registration is only ever created once in the app’s home tenant, however a service principal is created in each tenant where the application is used (including the home tenant), referencing the app registration object. Think of it like a class in object-oriented programming - the service principal inherits some of the properties of the app registration much like an instance of an object inherits some of the properties of its class.
How do I create an identity for my infrastructure as code deployments?
Given infrastructure as code is one of the key things I talk about on this site, I thought it would be useful to include the process here. This example focuses on Terraform.
- Create an application in app registrations and note the name and application ID.
- Generate a client secret or certificate from the Certificates & secrets blade of the application. If creating a secret, store it securely.
- Head to the enterprise applications blade of Azure AD and find your app. You can search using the app’s name or application ID. Note the object ID of the enterprise application/service principal object.
- To assign RBAC permissions to the resources you need, use the object ID of the enterprise application/service principal.
- Use the application ID and secret or certificate from the app registration to authenticate.
The Azure AD overview blade has a search bar that can be used to search your entire tenant for anything including users, groups, apps, devices etc. You can find more information here.