A software practitioner’s perspective

Introduction

Whether you manage an e-commerce platform or an internal business application, a robust Customer Identity and Access Management (CIAM) solution is essential to organizing and securing your customer data.

There are several CIAM providers or platforms, such as Auth0, Ping Identity, and AWS Cognito. These tools provide various authentication mechanisms, such as single-sign-on (SSO), Social Login, Service registration, and Multi-factor Authentication (MFA). In this article, we examine Azure Active Directory B2C (AD B2C) primarily based on our experience using it to implement CIAM features for customer-facing web portals.

It should be noted that this article may not serve as a learning guide or a comprehensive analysis of Azure AD B2C. The purpose of this article is to help someone starting with the tool to let them know what to look for. We will take you through some common pitfalls and workarounds based on our experience using the AD B2C. Meaning, this article contains observations and opinions. However, we assume those observations and opinions will be useful for someone considering to use AD B2C, such as Solution Architects and Software Engineers.

Azure AD B2C — What is it?

It is important to know Microsoft Active Directory and Azure AD (aka Microsoft Entra ID) to understand Azure AD B2C.

• Microsoft Active Directory — is a centralised directory service developed by Microsoft that manages and controls network resources such as users, computers, and permissions within a Windows environment. It provides authentication, authorisation, and policy enforcement through features like domain services, Group Policy, and role-based access control. AD is widely used in organisations to ensure secure access to resources, manage user identities, and support scalability across complex IT infrastructures.
• Azure Active Directory (Entra ID) — is a fully cloud-based identity and access management service from Microsoft, designed to provide secure access to applications and resources in the cloud and on-premises. It supports authentication, single sign-on (SSO), multi-factor authentication (MFA), and identity protection for users and applications. Organisations use Azure AD to manage user identities, secure access to cloud services, and integrate with other Microsoft and third-party platforms.

While these two solutions excel at managing organizational structures and user identities, they offer limited support for building customer-facing applications.

Azure AD B2C is a business-to-customer (B2C) solution built on the same technologies as Azure AD but with different functionality and purpose. It is primarily designed to manage the identities of external users, allowing businesses to offer their customers sign-in, registration, and profile management functionalities. It supports social identity providers, e.g., Google, Facebook and local accounts, i.e., email or username/password).

In a sense, Azure AD B2C can also be seen as a directory solution, but it is designed for consumer-facing applications. AD B2C allows businesses to build CIAM features with customisable authentication flows and user interfaces, allowing businesses to offer a branded user experience.

In the next three sections we will describe our experience using Azure AD B2C.

The Good

Scalability and reliability

Having built on the Azure cloud platform, the Azure AD B2C benefits from Azure’s global infrastructure to provide excellent scalability and reliability compared to its competitors. It can scale to handle millions of users and authentications without performance degradation, making it suitable for both small businesses and enterprises with large customer bases.

Security and compliance

Azure AD B2C offers enterprise-grade security features, including multi-factor authentication (MFA), Conditional Access, encryption of user data, and compliance with security standards such as GDPR, ISO 27001, SOC 2, etc.

Data residency

Businesses operating in different regions can ensure they meet local data protection regulations by storing customer data within specific geographical regions. Some competitors of AD B2C might not have the same global presence or data residency options, making Azure AD B2C an appealing option for global companies.

Seamless integration

AD B2C provides an enterprise-grade, seamless integration with other Microsoft products. This makes Azure AD B2C for businesses already heavily invested in Microsoft services such as Office 365 and Sentinel.

In addition, via custom policies, the authentication flows can be integrated with third-party APIs and tools. We found this extremely useful as it allows us to integrate external systems such as CRMs and Communications services into our authentication process, e.g., validating customer registration data, setting up email templates, etc.

Less expensive to start with

AD B2C operates on a pay-as-you-go pricing model. It does not require a subscription or dedicated pricing tiers. In addition, its pricing model is based on Monthly Active Users (MAs). To get an idea, at the time this article is written, it is free for the first 50K MAUs (Premium P1). Thereafter, it is $0.004786 / MAU. This means even small organisations can easily start using it without committing to high upfront costs.

No built-in identity proofing

Identity proofing refers to verifying a user’s identity using external verification sources, like government-issued IDs, biometrics, or other data sources. Azure AD B2C (Azure Active Directory Business-to-Consumer) does not have built-in identity proofing. In comparison, Okta, Ping Identity, and Auth0 provide built-in support for identity verification and proofing, streamlining processes for verifying a user’s identity with government-issued IDs or other credentials.

The Bad

Limited social identity providers

Social identity providers allow users to use their social accounts for authentication, and this is increasingly becoming a popular option for onboarding external users into an application. Although Azure AD B2C supports major social identity providers (like Google, Facebook, and Microsoft accounts), the number of pre-built identity provider integrations is smaller than some competitors. For instance, Auth0 relatively has support for many identity providers. In AD B2C, it is required to have custom development and integrations to support their other social identity providers.

Lack of support for reporting and analysis

Azure AD B2C does not provide robust built-in reporting and analytics features. While basic auditing is available, users often rely on external tools like Azure Monitor, Azure AD logs, or third-party analytics services to gather deeper insights into user behaviour and security events.

Pricing complexity

Azure AD B2C’s pricing can become complex, especially when dealing with large volumes of users or specific features like multi-factor authentication (MFA). The pricing is based on monthly active users (MAUs), and additional charges can apply for certain services like MFA, which can be cost-prohibitive for smaller organisations or those with fluctuating user bases.

No RBAC

Role-based access Control (RBAC) is a method of managing access to resources in a system by assigning specific roles to users based on their responsibilities within an organisation. Each role comes with a defined set of permissions that determine what actions the user can perform and which resources they can access. Unfortunately, Azure AD B2C does not have out-of-the-box support for RBAC.

And the Ugly

UI customisations

One of the highlighted benefits of AD B2C is its ability to provide a branded user experience. That means developers should be able to easily customise the default AD B2C user interfaces to include company branding. However, from our experience, this capability comes with some drawbacks, mainly due to the way AD B2C provides UI customisability.

The HTML templating provided by AD B2C allows customising the default UI. Users can define a div element as follows in their HTML template.

<body>
    <div id="api"></div>
</body>

The AD B2C content, such as the sign-up/sign-in form, is later added under this element. Any static content outside this element can be easily customised using HTML/CSS. However, the trouble starts when the given UI design demands customisations to the contents of this element, e.g., the sign-up form.

For example, assume you have to hide or re-order form elements. In these cases, as a developer, you would have to write jQuery that relies on the B2C provided HTML contents via their ID attributes. That means jQuery has to be used to locate these elements and perform the dynamically required changes. For clarity, a sample script is given below.

$("#smsOtpVerificationControl_but_verify_code").addClass("btn btn-primary");
$("#smsOtpVerificationControl_but_send_new_code").detach().insertBefore("#smsOtpVerificationControl_but_verify_code");

This is cumbersome due to the following reasons.

• If these ID attributes are changed, e.g., due to changes to custom policies or a version upgrade, the UI will be broken.
• For certain elements, the IDs may not be available (B2C doesn’t always add IDs). This means you have to write tricky selectors in jQuery and ensure they are reliable.
• The feedback cycle after a code-change is long as the changes need to be deployed in Azure, e.g., as a Blob Storage—even the static content.
• Styling issues can appear due to timing issues between the browser’s execution of the jQuery script and the rendering of the HTML.

In summary, the HTML template approach provided by AD B2C is convenient as long as the UI design does not radically deviate from the default UI.

Custom policy implementations

Azure AD B2C provides built-in user flows, e.g., predefined configurations for common scenarios like sign-up, sign-in, and password reset. Custom policies can be used to customise the user journeys further.

While custom policies are great for customising the authentication flows, there are a number of unattractive aspects of its AD B2C implementation.

• Custom policies are written in XML. Unless you have a special affection for XML, the industry has moved to better-readable formats. Having the files in XML makes them extremely unreadable, making it time-consuming to understand and apply the modifications.
• The language to implement these custom policies are verbose. Partly due to being defined in XML(syntactically) and in the grammar itself. From experience, these custom policy files can easily be extended beyond 400/500 lines of code, making it inescapable to scroll up and down a screen. (Some of our policy files were more than 1000 LoCs)
• The declarative nature of defining naturally imperative orchestration steps of user journeys makes it hard to follow them. This becomes even more difficult when it comes to defining the preconditions and order of executions. To overcome the ordering problem, B2C provides an Order attribute in each OrchestrationStep.

Slow feedback loop

Software developers appreciate a fast feedback loop to boost their productivity. This is especially important when developing user interfaces.

In an ideal scenario, developers build their software in a local environment, get quick visual feedback, and then apply changes as needed. They repeat this process until they are satisfied with the result and eventually deploy it to a test environment.

Unfortunately, with AD B2C, once a change is made, be it UI assets or Custom Policies, it has to be deployed in Azure to get some feedback. Depending on the efficiency of the deployment mechanism, this could take a few minutes. Now, think of a developer adding a few changes to customise a Form Field or changing a Claim Type in Custom Policies. They have to wait for a few minutes to see their change.

There are a few workarounds that can be applied to a certain extent, e.g., performing modifications in a browser and then applying them to the code. However, we feel the design of AD B2C is fundamentally flawed in this aspect and should’ve paid more attention to developer experience.

Documentation

So many tool-specific concepts need to be learnt just to get going. Even for someone with a reasonable knowledge of CIAM concepts, it is hard to map the common knowledge in B2C jargon. This makes the learning curve steep for a newbie.

The documentation is heavily fragmented, making it hard to follow. For instance, when dealing with custom policies, we found that it was quite difficult to use the provided examples and adapt them to our needs. The examples, too, are fragmented and inconsistently scattered over many pages. This is in contrast to the documentation by other competitors, such as auth0 or Cognito.

Tips and Tricks

Visual Studio Code extension

Use the VS Code B2C extension to edit custom policies. Apart from the common features expected in a VS Code extension, e.g., auto-complete, tool tips etc., it comes with a number of other handy features to compensate for some of the drawbacks.

• Automatically identify and increment the orchestration step numbering. This is useful to avoid the common mistake of skipping or duplicating step numbers.
• Smart copy/paste allows for the generation and inserting of only the necessary elements from a complex XML element structure.
• This feature automatically replaces the keys with the values from appsettings.json. When testing your code against multiple tenants, such as dev, test, and staging environments, it saves a lot of time.

So, using the extension if you are using the custom policies is highly recommended.

Avoid deviations

Where possible, avoid excessive deviations from the default UI structure and the authentication workflows. This will drastically reduce the possible pitfalls.

• UI: Align the UIs to that of the default screen and form structures. For example, avoid hiding or re-ordering default form elements such as input fields, buttons and form validator placeholders. This will allow the customisations to use CSS instead of jQuery.
• Auth workflows: Use well-defined custom policy patterns. This will allow fewer customisations to custom policies, reducing the pain of maintaining them.

Therefore, we recommend that the User Experience (UX) and Engineering teams collaborate when defining the UX for the authentication processes and screens.

Custom policy examples

The AD B2C documentation on custom policies can be overwhelming at the start. Rather than combing the documentation, look at some examples and see whether they can be used/adapted to support your authentication flow.

Pre-load jQuery

To address intermittent UI failures due to a timing issue between UI rendering and execution of jQuery-based modifications, consider preloading your Javascript files containing jQuery.

RBAC workarounds

Although there is no out-of-the-box support for RBAC, consider using conditional access via the custom policies for a similar effect. Please refer to this article here for more information.

Reduce feedback time

If you are practising DevOps to deploy and test your changes in custom policies, it may lead to a longer feedback loop. To avoid this, consider directly uploading the changed files via Azure Web Portal. At least during the early stage of development. If you do not have permission, consider setting up your own tenant.

In addition, for UI styling-related changes, try them in the browser, e.g., using Chrome Dev Tools, before adding the changes to B2C UI assets.

Conclusion

In this article, we looked into Azure AD B2C from a software practitioner’s perspective. This report reflected some battle scars using it and also the excellent features it provides. We listed what is good in AD B2C as well as its limitations. In the end, we also provided some tips as workarounds for those limitations.

In conclusion, Azure AD B2C is a good choice as a Customer Identity and Access Management solution due to the wide variety of features it provides. However, the way these features are implemented, the journey is not smooth sailing if there are significant deviations in the design. Therefore, it is important to be aware of possible pitfalls. UX and engineering teams should work together to design the authentication flows and stick to the common flows as much as possible.