In this series of articles, we'll dive into questions like:
What was our experience with Azure Active Directory B2C identity as service?
Why we won’t be using it any time soon.
Issues with custom frontend and Microsoft flows for authentication.
Horrific complexity of custom policies in XML.
User unfriendly release of custom policies to Azure.
What is Azure Active Directory B2C?
Azure Active Directory (Azure AD) is Microsoft's well-known cloud-based identity and access management service. It provides a massive set of tools to manage users and groups. Azure AD also offers multi-factor authentication, self-service password reset, role-based access control, and integration with various Microsoft and third-party applications.
Azure AD B2C (Business-to-consumer) is an extension of the Azure Active Directory, allowing businesses to create and manage user identities, streamline authentication processes, and deliver a seamless and secure customer experience across various digital platforms. This is done by creating an “Azure AD B2C tenant” in its own Azure directory – which is the first issue we had with this system.
Setting up Azure Active Directory B2C
Generally speaking, setting up AD B2C is simple. You just need the Azure subscription, where you add the new Azure resource, and afterward you simply follow Microsoft’s tutorial.
You actually need to be switched to directory with the tenant to manage anything in the Active Directory. Suppose you have to configure something connected to the tenant (like application registration or appinsights). In that case, you must constantly switch between subscription with your application and AD B2C tenant directory, which gets tedious after a while. Microsoft’s tutorial recommends adding your specific Azure AD B2C as a favorite to your Azure portal. Unfortunately, this is not very friendly for new developers since you can’t have all the resources for one project in one place. You also have to give extra permission to developers to be able to work on the “whole” project.
Next, you are asked to register your web application. Thankfully, it’s pretty straightforward since Microsoft introduced App registrations. This solution is very robust, and the only downside is a bunch of click-throughs before you get to your app when selecting your web or backend.
Perhaps the strongest arguments in favor of AD B2C is the speed of the setup. If you already have an Azure Subscription and are familiar with Azure, you can be ready for production in a matter of hours. Even if you are unfamiliar with Azure, you can be done in a day or two. And for the most part, it will work well enough. It will be scalable and available, and you will get great tooling coming along with it (Azure Portal, Active Directory tools, Microsoft Graph API etc.).
Afterward, you would use Custom Policies or User Flows to create paths for users to follow in order to register or log in. You can read about this in the second part of this series.
TLDR?
What is our overall opinion, and what do we recommend?
If you are developing a simple solution, you need it deployed quickly, and most importantly, you are already using Azure, we recommend giving Azure AD B2C a try. But like with most projects, the scope changes (usually for the bigger), and after a while, you might realize you would be better off creating this process (FE, Business logic, etc.) yourself and using an OAuth library like Openiddict or Microsoft’s .NET Identity Server.
