Protect Application with Azure AD — Part 1
1. Introduction and Setup
Azure Active Directory offers a robust architecture to protect your applications but also to grant access via OIDC.
In this series of 4 articles, I will guide you through all the steps to create a Front-end and a Back-end application, how to register them in Azure, how to deploy them inside App Service Plan and finally, how to enable Authentication and Authorization.
Available Articles
- Introduction and Setup (this article)
- Setup a Front-end Application with NET Core 3.1 and React
- Setup a Back-end Application with NET Core 3.1
- Additional notes and functionalities
1. Setup
First of all, you need an Azure subscription. If you do not have one, you can enroll, for free, the Microsoft Developer Program with MSDN and get 130 USD to spend every month, which is perfect if you are going to learn Azure.
When your subscription is ready, we can start by creating our Resource Group:
az group create --resource-group "aad-auth-weu-rg" --location "westeurope"Next step, after the resource group is available, we need to create a new App Service Plan which will be used to host 2 applications, the Front-end and the Back-end. You can do that via command or via ARM templates or via the User Interface of Azure. Personally I prefer az cli because it's an easier solution.
First, I setup as default my newly create group, so I can speed up a bit the process:
az configure --defaults group="aad-auth-weu-rg" location="westeurope"And then create the App Service Plan which will be our hosting environment:
az appservice plan create --name "aad-auth-weu-plan" --resource-group "aad-auth-weu-rg" --sku "S1"Finally, we need two web app, one for hosting the Front-end and one for hosting the Back-end
# Front-end
az webapp create --name "aad-auth-weu-front-wa" --resource-group "aad-auth-weu-rg" --plan "aad-auth-weu-plan" --runtime "DOTNETCORE|3.1"# Back-end
az webapp create --name "aad-auth-weu-back-wa" --resource-group "aad-auth-weu-rg" --plan "aad)-auth-weu-plan" --runtime "DOTNETCORE|3.1"
Now you should have 2 URL where your NET Core 3.1 apps are deployed:
2. Registration
In order to utilize AD Sign-in functionalities, you need to register an application inside Active Directory. For now, we will simply register both without any settings. We will come back later and configure each one.
az ad app create --display-name "aad-auth-weu-front-wa"az ad app create --display-name "aad-auth-weu-back-wa"
If you now open the Azure Dashboard and land into Active Directory, App registrations, you should be able to find them both:
As you can see, we get immediately an Application ID, which is also called Client Id or AppId, it depends on the library you are going to use for authentication.
Last step, for our Front-end, which will be hosted inside https://localhost:5001/, we will add a couple of configuration settings to be able to execute the next article.
3. Authentication model
Azure Active Directory is implementing OIDC specifications which offers 4 different authentication models:
- implicit-grant-flow
- Bypass the authorization step and exposes directly the /Token endpoint
- Non standard anymore because it supports only Cookie - auth-code-grant
- It is used to grant access and secondly provide access tokens
- It requires a redirect URL to receive authorization token, which can be stored in various browser storages, for example the session storage - on-behalf-of
- it propagates the caller credentials
- with Microsoft, it requires the MSAL library to have an intermediary validator - client-credentials
- authorize the entire application
- it does not know who is the human calling the API
What's the difference and when should I use one or another? For our purpose, we will use the auth-code-grant as suggested by Microsoft.
Next step, we will create a React App SPA with NET Core 3.1, enable Login and verify it.
