The first question is, What is Azure AD? So, the most important thing to understand about Azure AD is that it is not a replacement for your on-premises Windows Active Directory.

In fact, it is designed for internet scale and internet-based standards and protocols. So when you walk into work every morning, and you log on to your Windows computer typically on a domain, Azure AD does not change that. You’ll still use Windows Active Directory to manage PCs, mailboxes, groups, users, etc. Azure AD is more aimed towards internet scale, internet-based standards, protocols, and applications targeting cloud-based applications.




There’s a sign-in for work account or home or business account. Microsoft needed to get started with Office 365. They needed a good story for identity management. And, therefore, Azure AD was born.

If you sign into Office 365, you are authenticating against Azure AD. But they allow you to have an Azure AD without an Office 365 tenancy now. So Azure AD has been opened up so different sorts of applications, etc. can tap into Azure AD. It doesn’t have to be just Office 365. And over time, most Standards & Supports and APIs, protocols, etc., were added, and this later on extended to third parties. So third parties could start offering their apps and APIs inside Azure AD.

The good news is that as a developer, your programming paradigm does not change. No matter how Azure AD is set up, you really don’t need to worry for the most part about whether they’re using ADFS, whether they’re using Azure AD Connect or with password sync, without sync–it doesn’t matter. Your programming paradigm does not change.

Let’s understand how this authentication flow works, and then we will see it in our code and example. So at the very high level, you have three parties involved here.

You have the browser, you have your web application, which is registered with Azure AD, and it has got some specific code inside it that tells the website that it is indeed secure using Azure AD, and you have an Azure AD authentication endpoint. So this endpoint basically could be the out-of-the-box Azure AD endpoint, the simple sign-on process that you provide a username and password to Azure AD, or it could be a Federation-based endpoint.

17. Authentication workflow

A web browser/web application scenario is simply cookie-based authentication.

Now, what happens when the session expires? So, in this scenario, you have to basically think of token expiration as the lifetime of the cookie. So the web application author decides when the session expires by simply extending the lifetime of the cookie. That’s all. And if this session expires, then the user has to sign in again. There’s no automatic sign-in functionality.

There’s a concept of OAuth and refresh tokens, You’ll see this while workign with native applications.



We will create a simple web app using ASP.NET MVC. And then we will enable it to be protected by Azure AD. And then we will register it in Azure AD. And then we will access it via web browser and see how it works.

Step#1: Add users

1. Add Users


Step#2: Register the app
To secure the app using Azure AD, our application should trust Azure AD. Similarly Azure AD will need to know about our application to trust it. This can be achieved by simply adding the application in our Azure Active Directory Tenant.

2. Register app


Step#3: The registration process will give me a ClientId

3. Get the application ID


Step#4: Create a simple ASP.NET MVC application
Select the template as MVC, authentication as “No Authentication” and uncheck the checkmark of “Host in the cloud” for now. Click Ok to proceed ahead and create the application.

14. New application


Step#5: Configuring Https
We need to configure the project to run on https.

15. Enable SSL


Step#6: Project URL

16. Project Url


Step#7: Important nuget packages
Open “Package manager console” and run the following commands to add required references to the application.


Step#8: Update the web.config to make our application know about Azure AD.

4. Update the config file


Step#9: Debug in Incognito mode
I’m going to go ahead and open a private mode or an incognito mode Chrome browser window here. When you work with Azure AD, we’re going to do this incognito mode quite a lot because I have a session running back here under this user account, and now I want to sign in using a new user. So I need an incognito browser window because I don’t want the two sessions to get confused with each other.

5. Change the debug browser

6. Set it to chrome incognito

7. Set as default


Step#10: Configure Startup class


Step#11: Configure Login page
In Views > Shared folder, right click on Add New Empty View. Name it as _LoginPartial.cshtml. Replace the code in this file with the one given here


Step#12: Update the Layout page
Now we need to link this _loginPartial.cshtml on layout page as highlighted below, therefore change the code of Layout.cshtml to the following code


Step#13: Add a controller




Step#14: Run the application and click on SignIn button.

11. Sign in

12. Supply credentials

13. Logged in