Entra ID Application Key Concepts & Background

Most of the content here is also represented at https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added. Because everyone learns information slightly differently, you may find one or the other easier to understand.

Microsoft has a few terms which can be a bit confusing if you don’t understand what they mean:

• Entra ID Application: an identity intended to be used by an application with a bit of configuration about how that identity can be used. The fact that Azure is in the name does not designate where the software lives but that the application will only trust sign on tokens issued by Entra ID. The fact that application is in the name does not imply that this is a software platform for development or hosting.
• Application object: This is the single, definitive object with configuration details, and is only present in one Entra ID tenant. Think of it as the template by which many instances of this application might be created from.
• Service Principal object: This is a working instance of the application. This object will contain operational configuration information specific to this instance of the application and is linked to the application object.
• Enterprise application: This is a location in the Azure Portal where you can manage service principals. It is also the only location from which pre-integrated 3rd party SaaS applications in the Entra ID application gallery can be created (the application object does not exist in the UW tenant). The creation of service principals from this location can only be done by UW-IT.
• App registration: This is a location in the Azure Portal, where you can create and manage application objects (in the UW tenant). Anyone with a UW Microsoft account can create an application object, and a service principal is automatically created at the same time.

1. There are many meanings of the word “application.” When we talk about an Entra ID Application, we are talking about something very specific. An Entra ID Application is a digital identity and some associated configuration which informs Entra ID about how to treat software which uses that digital identity. The software itself may be running anywhere, on any platform, written in any language. To be more specific, if software needs to request Entra ID logon tokens or consume Entra ID logon tokens, then it must be an Entra ID application. The software might have other digital identities it uses, but that topic isn’t covered here.
2. An Entra ID application is represented by two types of objects in Entra ID:
   1. An object of type application. This is the core digital identity with the basic required configuration details, and is only present in the Entra ID application’s home tenant.
   2. One or more objects of type service principal. This object will be present in each tenant which has an instantiation of the Entra ID application, except the Entra ID application’s home tenant. This object will have the specific role assignments and user consent permissions granted for that tenant.
      Note: An Entra ID application’s instantiation in a given tenant is the service principal object–but that service principal references the “primary” Entra ID object of type application that lives in one and only one tenant. You can read more about these Entra ID objects here.
3. All Entra ID applications involve consent of some kind. There are generally two kinds of consent:
   1. User consent. The end user is presented with a list of permissions the Entra ID application would like, if you agree to grant them. If the user does not consent, then they can not use the application.
   2. Admin consent. The tenant admin is presented with a list of permissions the Entra ID application would like. Admin consent is required if the required application permissions are broader in scope than what an individual user can grant for themselves. If admin consent is required, then no user can use the application until admin consent. Optionally a tenant admin can provide the user consent decision on behalf of all users. In this case, the end user never sees the user consent dialog.
   3. An Entra ID application instance will record all consent permissions granted within that tenant related to itself (on the service principal object).
4. OAuth permission scopes are one of two kinds: application or delegated.
   1. Application permissions are those which are used solely by the application identity itself. You use these type of permissions for a non-interactive application that is doing work without a human interacting with that application. Application permissions require admin consent because there is no user consent experience by design.
   2. Delegated permissions are those which require a user to interactively sign into the application. The user consents to the permissions, which authorizes the application to act on behalf of the user with the permissions which that user has consented to. If an admin consents to delegated permissions then users don’t consent.
5. Entra ID Applications come in two fundamental flavors–confidential clients and public clients. Confidential clients need to authenticate as themselves, so must have credentials–these are typically web apps or code used to programmatically leverage the API of another Entra ID application. Public clients do not need to authenticate as themselves and typically represent native clients broadly distributed on many devices. So the key differentiator here is whether the application needs to get a logon token for itself–and that is usually dependent on whether it needs to access another Entra ID application. Most Entra ID Apps will be confidential clients. Note: public clients do not have a service principal in each tenant–they are only ever present in the developer’s tenant. If you’d like to explore public clients further, you might review the ‘Native Application to Web API’ section of https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/.
6. If an Entra ID Application needs a credential, then it has two options–a password or a cert. See more here.
7. An Entra ID application may define whether it is available to other tenants.
8. An Entra ID application must define what permissions to other Entra ID applications it needs. To only authenticate other users, you do not need any permission, but if you need to include name or other basic data in the user experience, then you will likely need User.Read, i.e. the ability to read the profile of an Entra ID user who has logged into your application. You can read more about permission scopes, including the permission scopes that Entra ID itself has available at https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes.
9. An Entra ID application may define permission scopes that can be granted to other Entra ID applications. This is optional.
10. Entra ID application assignments
    1. Each app may define roles which users can be assigned to. This is optional. Each Entra ID application instance will record any role assignments.
    2. Each Entra ID application instance may require assignment of users or groups to be able to access to the app. This is optional. Note that if assignment is required, a basic role is created even if the application doesn’t define any roles.
    3. Each app can have owners defined, but they are not represented in the roles property. Application Owners have a broad set of permissions.
11. An Entra ID application records the URIs that tokens it requests are issued to. A given Entra ID application may have many valid URIs. You might imagine using the same Entra ID application for a production, pre-production, and development instance of the code behind your Entra ID application, each with their own distinct URI. Or you can create a separate Entra ID application for production, pre-production, and development purposes.