Azure AD 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:

• Azure AD 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 Azure AD. 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 Azure AD 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 Azure AD 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 Azure AD Application, we are talking about something very specific. An Azure AD Application is a digital identity and some associated configuration which informs Azure AD 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 Azure AD logon tokens or consume Azure AD logon tokens, then it must be an Azure AD application. The software might have other digital identities it uses, but that topic isn’t covered here.
2. An Azure AD application is represented by two types of objects in Azure AD:
   1. An object of type application. This is the core digital identity with the basic required configuration details, and is only present in the AAD 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 AAD application, except the AAD application’s home tenant. This object will have the specific role assignments and user consent permissions granted for that tenant.
      Note: An AAD application’s instantiation in a given tenant is the service principal object–but that service principal references the “primary” AAD object of type application that lives in one and only one tenant. You can read more about these AAD objects here.
3. All Azure AD 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 AAD 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 AAD 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 AAD 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. Azure AD 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 AAD 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 Azure AD application. Most Azure AD 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 Azure AD Application needs a credential, then it has two options–a password or a cert. See more here.
7. An Azure AD application may define whether it is available to other tenants.
8. An Azure AD application must define what permissions to other AAD 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 Azure AD user who has logged into your application. You can read more about permission scopes, including the permission scopes that Azure AD itself has available at https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes.
9. An AAD application may define permission scopes that can be granted to other AAD applications. This is optional.
10. AAD application assignments
    1. Each app may define roles which users can be assigned to. This is optional. Each AAD application instance will record any role assignments.
    2. Each AAD 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 AAD application records the URIs that tokens it requests are issued to. A given AAD application may have many valid URIs. You might imagine using the same AAD application for a production, pre-production, and development instance of the code behind your AAD application, each with their own distinct URI. Or you can create a separate Azure AD application for production, pre-production, and development purposes.