Application and service principal objects in Azure Active Directory
When you read about an Azure Active Directory (AD) "application", it's not always clear exactly what is being referred to by the author. The goal of this article is to make it clearer, by defining the conceptual and concrete aspects of Azure AD application integration, with an example of registration and consent for a multi-tenant application.
An Azure AD application is broader than just a piece of software. It's a conceptual term, referring not only to application software, but also its registration (aka: identity configuration) with Azure AD, which allows it to participate in authentication and authorization "conversations" at runtime. By definition, an application can function in a client role (consuming a resource), a resource server role (exposing APIs to clients), or even both. The conversation protocol is defined by an OAuth 2.0 Authorization Grant flow, with a goal of allowing the client/resource to access/protect a resource's data respectively. Now let's go a level deeper, and see how the Azure AD application model represents an application internally.
When you register an application in the Azure classic portal, two objects are created in your Azure AD tenant: an application object, and a service principal 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, referred to as the application's "home" tenant. The application object provides identity-related information for an application, and is the template from which its corresponding service principal object(s) are derived for use at run-time.
You can think of the application as the global representation of your application (for use across all tenants), and the service principal as the local representation (for use in a specific tenant). The Azure AD Graph Application entity defines the schema for an application object. An application object therefore has a 1:1 relationship with the software application, and a 1:n relationship with its corresponding n service principal object(s).
The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. The Azure AD Graph ServicePrincipal entity defines the schema for a service principal object.
A service principal object is required in each tenant for which an instance of the application's usage must be represented, enabling secure access to resources owned by user accounts from that tenant. A single-tenant application will have only one service principal (in its home tenant). A multi-tenant Web application will also have a service principal in each tenant where an administrator or user(s) from that tenant have given consent, allowing it to access their resources. Following consent, the service principal object will be consulted for future authorization requests.
Any changes you make to your application object, are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). For multi-tenant applications, changes to the application object are not reflected in any consumer tenants' service principal objects, until the consumer tenant removes access and grants access again.
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
- Adatum - the tenant used by the company that developed the HR app
- Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
- Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
In the previous diagram, Step 1 is the process of creating the application and service principal objects in the application's home tenant.
In Step 2, when Contoso and Fabrikam administrators complete consent, a service principal object is created in their company's Azure AD tenant and assigned the permissions that the administrator granted. Also note that the HR app could be configured/designed to allow consent by users for individual use.
In Step 3, the consumer tenants of the HR application (Contoso and Fabrikam) each have their own service principal object. Each represents their use of an instance of the application at runtime, governed by the permissions consented by the respective administrator.
An application's application object can be accessed via the Azure AD Graph API, as represented by its OData Application entity
An application's service principal object can be accessed via the Azure AD Graph API, as represented by its OData ServicePrincipal entity