OAuth – Part 04 – Understanding Service Principal

In my previous blog post, we have gone ahead and registered an application in Azure Active Directory and then create an application account in Business Central. As the last step, we have granted permission from Business Central.

In this blog post, I’m trying to briefly explain what we did in a little bit more detailed way.

Application registration

When you complete the app registration, you have a globally unique app (the application object) that lives within your home tenant or directory. You also have a globally unique ID for the application (the app or client ID). In the portal, you can then add secrets or certificates and scopes to make your application work, customize the branding of the sign-in dialogue, and more.

If you register an application in the portal, your home tenant automatically creates an application and a service principal object. Creating the service principal object is separate if you register/create an application using the Microsoft Graph APIs.

Application object

An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered (known as the application’s “home” tenant). An application object is used as a template or blueprint to create one or more service principal objects. A service principal is created in every tenant where the application is used. Like a class in object-oriented programming, the application object has some static properties applied to all the created service principles (or application instances).

The application object describes three aspects of an application:

  1. How the service can issue tokens in order to access the application.
  2. Resources that the application might need to access.
  3. The actions that the application can take.

You can use the App registrations blade in the Azure portal to list and manage the application objects in your home tenant.

Service principal object

To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This requirement is true for both users (user principal) and applications (service principal). The security principal defines the access policy and permissions for the user/application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.

There are three types of service principal:

  1. Application
  2. Managed identity
  3. Legacy

You can use the Enterprise applications blade in the Azure portal to list and manage the service principles in a tenant. You can see the service principal’s permissions, user consented permissions, which users have done that consent, sign-in information, and more.

Application Service Principal

The type of service principal is the local representation, or application instance, of a global application object in a single tenant or directory. In this case, a service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.

When an application is given permission to access resources in a tenant (upon registration or consent), a service principal object is created. A service principal is created automatically when you register an application using the Azure portal. You can also create service principal objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, and other tools.

Relationship between application objects and service principals

The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant. The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects.

An application object has:

  • A 1:1 relationship with the software application, and
  • A 1:many relationship with its corresponding service principal object(s).

A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant. A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant application also has a service principal created in each tenant where a user from that tenant has consented to its use.

I end up taking most of the content from the Microsoft article but if you want to read the full Microsoft blog use this link.

Thank you and Regards,
Tharanga Chandrasekara

Click on a star to rate it!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?