Building a Web Application that Supports both Azure AD and Azure AD B2C

Published by Mika Berglund on

Many locks

When Azure AD B2C was first announced several years ago, one of the key selling points were that from an application’s point of view, it is just another Azure AD instance. You don’t have to make changes to your application to switch between Azure AD and Azure AD B2C.

Still, many of the samples out there that demonstrate how to use Azure AD B2C in your application use the Microsoft.AspNetCore.Authentication.AzureADB2C.UI Nuget package, effectively making the application into an Azure AD B2C -only application.

So I set out to examine how to build your application on just Open ID Connect specific code, and switch between Azure AD and Azure AD B2C just by changing the application configuration. This article describes the tasks you need to perform to make your ASP.NET Core application into an “identity provider agnostic” application relying only on Open ID Connect.

Source Code

To make it easier for you to follow, I created a repository on GitHub that contains the source code that I’m describing in this article. I’ve structured the code so that it starts with an empty ASP.NET Core web application, and each commit represents a step that you need to take in your application.

The list below outlines the commits. I’ll go into more detail on the most important commits in a separate chapter below.


I’ve described the most important commits in the chapters below.

Razor Page Support (commit)

This is not required to wire up Open ID Connect. However, you need some kind of UI stack to provide the user with the ability to sign in and out. Razor pages is just so much simpler than for instance MVC, but still allows for server-side code execution. This is why I chose Razor pages over MVC.

Open ID Connect Wiring (commit)

This is the first actual Open ID Connect related change in the application. The majority of the changes required are done in the Startup.cs file. This is where you set up the Open ID Connect middleware using your application’s configuration.

You also need to remember to add a reference to the Microsoft.AspNetCore.Authentication.OpenIdConnect Nuget package to your web project in order to be able to add the required code to your Startup class.

This commit also contains a markdown file where I describe the necessary configuration in detail. In order to run your application in your own environment, you need to create the appsettings.local.json file, as described in the markdown file. I have excluded the file from the code repository, because it contains sensitive information.

Lately, I’ve picked up the habit of describing files that have been excluded from source control as markdown files with the same name as the excluded file, with an .md extension. This markdown file contains all the necessary information another developer needs to reproduce the excluded file. Without exposing any sensitive information, of course.

When you add Open ID Connect authentication to your application, you can specify many of the options in your configuration file. The code on this line maps your configuration data to Open ID Connect options.

The event hander on this line allows you to perform actions when a user is logging in to your application. For instance, you augment the claims of the user by adding them to the Claims collection. To do this, you can connect to any system to extract the information from. These claims are available to the application throughout the session of the user.

Controller and UI (commit)

The second, and last, thing you need to do is add a controller. This controller takes care of sending your users to the authority for logging in. The controller also takes care of logging your users out of the application.

Both actions in the controller are defined with RouteAttribute class that specifies the route that the action represents. I find using attribute routing a more explicit and explanatory way of specifying the routing. You can still achieve the same with conventional routing too. It is just my personal preference.

The Index.cshtml file has changed, and contains links to the controller actions. It just demonstrates the absolute minimum you need to do. You will of course do it differently. Links to sign in and out point to the same controller action regardless of your implementation.

Switching Between Azure AD and Azure AD B2C

So now you have wired up the application for Open ID Connect. You can switch between Azure AD and Azure AD B2C just by changing the configuration.

In either case, you need to register an application in the directory that you are using. The ID of the application (Client ID) needs to be stored in the configuration. This article describes how you do that in Azure AD. For information on how you do that in Azure AD B2C, head over here to read more.

The rest is then just a matter of configuration changes. I’ve documented this in quite detail in the file in the code repository, so please have a look at that to learn more. The only actual difference is the Authority property, which is constructed differently depending on whether you are using Azure AD or Azure AD B2C.


As you can see, it is pretty simple to create an application that you don’t have to hard-wire to either Azure AD or Azure AD B2C. In fact, the same application could be wired up for any identity provider that supports Open ID Connect with just changes to the configuration, mainly the Authority and ClientId configuration properties.

The OpenID website has a long list of certified SDKs, products and services that you can use with Open ID Connect. As you can see, Open ID Connect is so much more than just Azure AD. In fact, the list does not even mention Azure AD nor Azure AD B2C. Still, Azure AD and Azure AD B2C both fully support Open ID Connect.


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *