Azure AD App registration, an introduction

In house business applications require to deal with enterprise authentication. Business users do not want to use a new login/password for each new application. Ops want applications to use Active Directory securely and not compromise the security of their infrastructure. Dev wants to concentrate on the business value of the application and not in the login process.

Here’s come the Microsoft Identity Platform and Azure AD app registration. It offers developers a simple and secure way to provide secure sign-in to an app or/and access to other Azure resources like Graph API, SharePoint, … It’s also capable to protect in house API. It let Ops manage assignation and rapidly grant or revoke permissions.

To do that you need to register the application in Azure Active Directory and use one of the authentication/authorization libraries provided by Microsoft.

But the process is not always frictionless. How to do that, how to make Ops understand the process and how to govern it and get velocity needed by developers and the security and the stability wanted by Ops and the security teams?

First, we need to understand what's behind app registration, what are the concept and the scenarios. In a second time, we need to see how to perform the registration and then how to manage them. Of course, how to automate the entire process out of the portal.

Let start with applications. In Microsoft Identity Platform or MIP, an application can be anything, a web page, an API, a mobile application, even a script can be an application. The purpose of MIP is to provide a secure sign in for both Applications and API and give permission to services such as Graph API or other Microsoft Services.

Let’s take some examples;

Imagine a scenario, an in-house web app opens the enterprise user and also to people with a Microsoft account or a Twitter account. In this case, we can talk about an authentication process. MIP act as an identity service to verify the user is who she/he says she/he is.

Imagine a second scenario, a mobile application that can give some information about your current location and list the last the next 5 meetings from their outlook calendar and the time they need from their current location to go to the meeting room. Here we have the same concept of authentication, verify the user claim that she/he is what she/he pretends. But there is another concept, authorization, we need the consent of the user to access some information (i.e. his name, email, …) and access to the user's calendar.

There two concepts here, authentication or AuthN, when you challenge an identity to prove who you are and authorization or AuthZ, when you are granted after authentication to resources.

With MIP the authorization can be divided into two parts consent and permissions.

Consent is the action from the user or a directory administration to see what the app will see from them and accept or refuse

Permissions are the action of giving the app a privilege on one more resource, here the ability to read the user’s calendar.

Permission can be described as how the application can access resources on behalf of the sign-in user.

There are two types of permission with the MIP platform. The delegated permissions where the user is present and where the user or the administrator (it depends on the resource to be used) consent the use of the resource. The permanent permission, where the application can use the resource event if the user is not connected and here only the administrator can give permission.

The MIP uses the OAuth 2.0 and OpenID authorization flow model which define four actors during the authentication flow:

• The user, the resources owner, he/she use the application/web pages and give permission

• The application, it acts as an OAuth client, it requests token and consumes resources on behalf of the user

• The Microsoft Identity platform, the authorization server. It issues tokens, grant or deny access to resources and verify users and applications claims

• The user's resources, on a Resource Server, it's the access point for the user's data. It’s generally based on Graph API

OAuth 2.0 and OpenID are the two faces of the same coin. OpenID is used for authentication (AuthN) and OAuth 2.0 for authorization (AuthZ).

The process uses endpoints. You can get the information by using PowerShell and the AZ Module to query the oAuth 2.0 metadata document.

$TennantId = (Get-AzTenant).id[0] 

$oAuth2TenantInfmation = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$($TennantId)/v2.0/.well-known/openid-configuration" -Method get 

The $oAuth2TenantInfmation contains all the endpoints and information you need.

To get the authorization endpoint:

$oAuth2TenantInfmation.authorization_endpoint 

In the AuthN phase, the user is redirected to an endpoint in Azure (https://login.microsoftonline.com/**/oauth2/v2.0/authorize where Tenant ID is used for the current tenant, Common for any works or Microsoft account, Consumers for Microsoft account only and Organization for works account only).

The user enters his/her credential, consents to the permissions and get a token (ID_token) to return to the application (via the return URL). The application can verify the token to identify the user.

This is the basic authentication/authorization process with OpenID/oAuth 2.0

Microsoft provides several libraries and frameworks to deal with the authorization/authentication process see

To be able to sign in and access resources an application needs to be registered to Azure Active Directory. But before going further in application registration there are few other concepts to understand.

First, you need to determine who will use the application? There are several cases:

• Restricted to one Azure AD tenant, this is the case for most in house application
  
  The endpoints URI contain the tenant ID

• Open to any Azure AD tenants, this is the case for multi-tenant applications
  The endpoints URI contains organizations

• Open to anyone including other Azure AD tenants and Microsoft accounts, this the case for public applications
  The endpoints URL contain Common (or consumers if the application only accept Microsoft account)

Another thing is how the application works and behaves. It will determine which client library to use and how permissions consent.

We need to look at how the application interacts with the user. Does the application interact directly with the user or does it need to work whiteout any user interactions?

In other words, for an application that reads the user calendar, does it read it only when the user opens the application or every time in a background task on the server side.

In the same way how the application works, is it a Front/back application, an API or desktop application?

These two questions help to choose the correct library and how permission and consent can be set up.

Application Scenarios	Libraries	Permission assignment	Audience	Registration
Single Page App or Front/back app (React.js,...)	MSAL.js	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI
Node.js web app	Passport.js	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI and Logout URI
.net web App	Identity model extensions for .NET and MSAL.net	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI and Logout URI
Python web app	MSAL.python	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI and Logout URI
Java web app	MSAL.java	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI and Logout URI
Web app calling a web API	MSAL with ConfidentialClientApplication	User or tenant administrator	Works, Microsoft Account or Azure B2C	Secret or Certificate
Desktop app calling a web API	MSAL with PublicClientApplication	User or tenant administrator	Works, Microsoft Account or Azure B2C	Redirect URI
RestFull API	MSAL	User or tenant administrator	Works or Microsoft Account	Change the application manifest with AccessTokenAcceptedVersion = 2
Mobile App	MSAL with PublicClientApplication	User or tenant administrator	Works, Microsoft Account or Azure B2C	Need to add platform (IOS/Android), the Redirect URI will be computed by the system
Daemon	MSAL with ConfidentialClientApplication	Tenant administrator	Works Account only	Secret or Certificate

How can we register the application, as we see we may need a URI, sometimes a certificate or a secret?

App registration can be done in the Azure Portal or by using PowerShell. For PowerShell, you will need the AZ module. It works with Windows PowerShell 5.1 and PowerShell core

install-module –name AZ –scope CurrentUser  

Import-module –name AZ 



Login-AzAccount 



$ApplicationName = "DemoDev-To" 

$ApplicationUri = "https://DemoDev-To.azurewebsites.net" 

$ApplicationReplyUri = @("https://DemoDev-To.azurewebsites.net/signin-oidc","https://localhost:44321/signin-oidc") 

$AzureApplicationObject = New-AzADApplication -DisplayName $ApplicationName -IdentifierUris $ApplicationUri -ReplyUrls $ApplicationReplyUri –HomePage $ApplicationUri 

The ApplicationName will be displayed in the Azure Portal and will later identify the application.

For the ReplyUrls parameter, I used an array and not a string. An application can have multiple environments (Dev/UAT/Prod) and respond to different URI.

The $AzureApplicationObject contains the configuration result. You will get two important ID, ObjectID and ApplicationID. These two objects will be needed to configure the client library.

HomePage is not needed but it helps to identify the application later in the Portal.

Now let's try to create a Secret based application registration.

$ApplicationName = "DemoDev-To-Key"  

$ApplicationUri = "https://DemoDev-To-Key.azurewebsites.net"  



$ApplicationReplyUri = @("https://DemoDev-To-Key.azurewebsites.net/signin-oidc","https://localhost:44321/signin-oidc")  



$AzureApplicationObject = New-AzADApplication -DisplayName $ApplicationName -IdentifierUris $ApplicationUri -ReplyUrls $ApplicationReplyUri –HomePage $ApplicationUri  



$AppPlainTextPassWord = "SomethingYouCanType"  





$SecureStringPassword = ConvertTo-SecureString -String $AppPlainTextPassWord -AsPlainText -Force 



$StartDate = get-date 

$EndDate = $startDate.AddYears(2)  



New-AzADAppCredential -ObjectId $AzureApplicationObject.ObjectID -Password $SecureStringPassword -startDate $StartDate -enddate $EndDate 

Get-AzADApplication -ObjectId $AzureApplicationObject.ObjectID | New-AzADServicePrincipal -startDate $StartDate -enddate $EndDate 

`

Application is now created in Azure AD, you can now start to assign users.

This is the end of this short introduction about application registration. As you can see the subject can be complexes and it concerns both developers and ops.

Next time we will see how to setup permission to Microsoft API for a registered application and how to manage user and other stuff.