Azure AD App registration & Enterprise applications

Azure AD App registration ? Enterprise apps ? Admin consent ? User delegation access? Application delegation ?

Confused about the mumbo jumbo of Azure AD app registration and Azure Enterprise principal? Hearing these terms interchangeably ?

For me it was difficult to fathom but getting this right is crucial in order to understand a lot of other identify topics in Azure.

I read a wide variety of blogs to understand the concept in detail but more I read them, the more I got confused. 😊

But ever since I started working with App registration/ Service Principal, things became clearer and now I am writing my understanding down so that many like me can be benefitted.

First I’m just putting down the curated information from multiple Microsoft docs and other blogs that I have read.

A comparison chat between two subjects goes a long way in understanding the core of it rather than understanding from piecemeal documents and blogs.

Application Registration Vs Enterprise Application

Let us look at some of the examples for both so that we can get to see them in action .

Suppose we have an application and we want it to fetch data from the Azure SQL database. In order to connect to the database, our application can use the SQL username and password and connect and fetch that data.

Another example would be our application wanting to fetch secrets from the Azure key vault . Now , one way is to embed the username and password in the application code.

We do this by creating a fake account ( service account) , take the user id and password, add it to the code so that the application can use it to authenticate and fetch the required data.

But in Azure, all we need to do is to create a app in the Azure AD, copy the application ID, tenant ID of your organization, the client secret or certificate and use that to authenticate against the MS token endpoint to fetch access tokens ( so in effect we are delegating the App that we create to act as a mediator between your application and Azure AD )

The whole process will work if your application supports the modern authentication ( OAuth/ OpenID connect ) .

Access tokens issued by the Microsoft identity platform contain information (claims) that web APIs secured by the Microsoft identity platform, such as Microsoft Graph, use to validate the caller and to ensure that the caller has the proper permissions to perform the operation they’re requesting.

Authentication flow with Oauth as well as user ID, password means

What happens when we register an application in Azure AD?

When you register that application in Azure AD, Azure AD basically creates two aspects .1 ) An application object and 2) A Service Principal

Service principal is attached to the application object and it is then used to invoke or work with other Azure services. Important point to note is , there are permissions that get attached onto that service principal object which in turn gets attached to your application. We will see about the permissions in more detail below.

Your application can now securely access resources that are part of your Azure subscription through Azure AD

Simple to understand right?

Before we move to another topics like Admin consent and delegations, let’s find out what these permissions are how are they attached to the Service Principal.

Microsoft Graph exposes granular permissions that control the access that apps have to resources, like users, groups, and mail. An application developer can decide which permissions to request for Microsoft Graph.

As a best practice, request the least privileged permissions that your app needs in order to access data and function correctly. Requesting permissions with more than the necessary privileges is poor security practice, which may cause users to refrain from consenting and affect your app’s usage.

Now in order for the application to claim these permissions and access data , it need ‘ approval’ from the user ( or the organization admin the case may be) .

This ensures transparency and also confidence to an end user to know prior to granting permissions to a third party app ( or even a first party app ) the kind of access he is consenting to.

When a user consent to this information ( who can consent can be controlled in Azure AD settings ) it is called an User consent and if this need consent from an Administrator ( Like Global administrator ) it is called as Admin consent.

When a user signs in to the app they, or, in some cases, an administrator, are given a chance to consent to these permissions. If the user consents, your app is given access to the resources and APIs that it has requested. For apps that don’t take a signed-in user, permissions can be pre-consented to by an administrator when the app is installed.

Microsoft Graph permission names follow a simple pattern: “ resource.operation.constraint “

For example, User.Read grants permission to read the profile of the signed-in user, User. ReadWrite grants permission to read and modify the profile of the signed-in user, and Mail. Send grants permission to send mail on behalf of the signed-in user.

Auth flow during Azure AD application registration and Admin consent grant screen

Now that we know what consent is , let us delve into Delegated and application permissions

Microsoft Graph has two types of permissions:

Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph. Some delegated permissions can be consented by non-administrative users, but some higher-privileged permissions require administrator consent.

Application permissions are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Application permissions can only be consented by an administrator.

Important

For delegated permissions, the effective permissions of your app will be the intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user.

Your app can never have more privileges than the signed-in user

For example, assume your app has been granted the User.ReadWrite.All delegated permission. This permission nominally grants your app permission to read and update the profile of every user in an organization. If the signed-in user is a global administrator, your app will be able to update the profile of every user in the organization. However, if the signed-in user is not in an administrator role, your app will be able to update only the profile of the signed-in user.

Important

For application permissions, the effective permissions of your app will be the full level of privileges implied by the permission. For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.

Security Tip !

1. When calling Microsoft Graph, you should treat access tokens as opaque. You must always transmit access tokens over a secure channel, such as transport layer security (HTTPS).

2. Always ensure you consent to apps only after verifying the publisher information. Always look for blue check mark in the consent grant screen.

More discussion on how to monitor consent grants, identify illicit consent grants, modifications to a Service principal etc. in another article..

That’s all for now.. See you in next Article!