Sign-in using both Azure AD and Azure AD B2C
In the last few months, I focused a lot of my commitment on the development of identity solutions for enterprise applications. In particular, I migrated different ASP.NET Core applications from LDAP-based local authentication (using Novell.Directory.Ldap.NETStandard library) to Azure Active Directory-based authentication (using Microsoft Authentication Library).
The last application that I am developing for Loccioni has an extra peculiarity, that of allowing registration and access to users outside the organization. It seemed to me the right opportunity to start testing the new Azure Active Directory B2C identity management service.
Honestly, I’m not here to explain how to configure a B2C solution, there are now dozens of tutorials that allow us to correctly configure a B2C tenant and start using it in our application thanks to Microsoft.Identity.Web library.
The main topic I would like to address concerns how to make two different identity providers coexist in a single application: Azure Ad and Azure Ad B2C.
But why?
The reason is very simple, the backend of this new application must be able to answer both requests from a mobile app provided to our customers and requests coming from an administration web spa used internally.
Let’s start immediately by listing a few possible solutions to satisfy this requirement:
- Federate the Azure AD B2C with the Azure AD and build two custom flows to be used one on the mobile app and the other on the admin portal.
See Add an identity provider to your Azure Active Directory B2C tenant and Set up sign-in for a specific Azure Active Directory organization in Azure Active Directory B2C - Deploying two different backends, in a microservices architecture, we could think of developing a backend with the sole responsibility of answering calls from the mobile application while another backend could answer the administration web portal.
- Introduce an Edge-Level Authorization service with a gateway role that takes care of correctly routing authenticated calls.
- Use different predefined Authentication Schemes for the identity providers. Es Bearer and Cookie, see Multiple Authentication Schemes.
- Use two OpenId authentication flows and then validate JWT tokens generated by the two tenants. See Best practices for N-tenant Azure AD applications.
- Use only one Authentication Scheme but validate different issuers. See Setting Up AzureAD Multi-tenant Authentication With ASP NET Core And Angular.
- Configure the backend to correctly handle two different authentication schemes based fully on the Microsoft Authentication Library (MSAL).
Following an agile methodology, the solution chosen for this implementation sprint was number 7. Try to configure two Identity Providers in the same ASP.NET Core application using MSAL.
How To
After having configured the tenants and registered web applications on the Azure portal, I began to understand how to best move between the different Authentication Schemes and how to configure them correctly during the startup phase.
In my case, I started adding single configurations using just AddMicrosoftIdentityWebApi method.
As you noted there is no default Authentication Scheme during AddAuthentication call.
How do we detect the correct Authentication Scheme when we receive authenticated requests?
In the ForwardDefaultSelector we can implement our Authentication Scheme selection logic, in my case I use a particular header value that mobile and web spa attaches to each request.
Another selection strategy could be to decode the JWT token to identify issuer value, for example:
What about Authorization?
Very simple, thanks to the ASP.NET Core it will be easy to define policies based on the Authentication Scheme used during the authentication phase:
What do you think? Tell me!
Please, Subscribe and Clap! Grazie!
