Skip to main content
IT Connect

Information technology tools and resources at the UW

Azure AD Application Basics

Related pages you might be interested in:

Risky Azure AD Application Request form

Azure AD Application Credentials

Azure AD Application Object Model

Azure AD Applications

Azure AD Applications are a complex topic. Throughout, keep in mind that an Azure AD Application is simply an identity 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. The fact that application is in the name does not imply that this is a software platform, for development or hosting.

To begin with we strongly suggest you review the basic concepts, then explore from there.

Basic Concepts

  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. Note that the software may have other digital identities it uses.
  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 “master” 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.

Other Important Concepts

Now that the basics are covered, there are a few other important concepts. These concepts are also covered on the Azure AD Object Model page, but in a more structured format.

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 AAD 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/.

If an Azure AD Application needs a credential, then it has two options–a password or a cert. See more here.

An Azure AD application may define whether it is available to other tenants.

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.

An AAD application may define permission scopes that can be granted to other AAD applications. This is optional.

An AAD application may define roles which users can be assigned to. This is optional. Each AAD application instance may require assignment of users or groups. This is optional. Each AAD application instance will record any role assignments. Note that if assignment is required, a basic role is created even if the application doesn’t define any roles. Note: applications can have owners defined, but they are not represented in the roles property.

An AAD application instance will record all consent permissions granted within that tenant related to itself.

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.