Azure Active Directory Business-to-Consumer (commonly called Azure B2C) is an important business solution for systems that need to authenticate end users to a web/mobile application using a white-labeled experience.
Azure AD B2C provides an easy identity system as a service with pay-as-you-go pricing options.
Who uses Azure AD B2C?
If you have a solution where you need end users to have the ability to self-service sign-up, self-service profile editing, or multi-organizational sign-ins, B2C is the preferred Azure solution.
Apart from the self-service authentication features, Azure AD B2C also provides authorization features just like those users are familiar with from the base Azure Active Directory service such as controlling access to API resources by authenticated users.
Azure AD B2C is designed to be used by IT administrators and developers. It is the go-to solution when you need custom branding on an application or website’s sign-in/sign-up processes.
What’s the difference between Azure AD?
While Azure B2C is built on the same technology as Azure AD and it shares a lot of common features and capabilities, it is designed to allow businesses to build customer-facing applications where anyone can sign-up and into those applications.
Some of the key differences between Azure AD and Azure B2C are summarized in the table below:
Common Steps for Implementing Azure B2C
Building a Tenant
To implement Azure B2C, there are several key steps to include. The first requirement is to construct a B2C tenant.
An Azure AD B2C tenant represents a collection of identities that should be logically grouped and used with relying party applications. Common patterns for configuring B2C tenants are:
- By Organization – E.g. Your company has multiple SaaS applications, and you want to allow users to access the different applications with the same account credentials.
- By System – E.g. Your company has one or more software systems that you would like to expose directly to customers. The user base will not be shared with other applications, so one tenant will be built per each system.
Read More: Understanding Group Types, Characteristics, and Capabilities in Azure AD and Microsoft 365
The key driver for how many B2C tenants will be required is how many separate unique user bases are required. There is no need to build different B2C tenants for different applications unless the user groups between applications must be kept separate.
Additional OpenID Connect providers can be added to the Azure Tenant under Azure AD B2C > Identity providers or via custom policies. This allows for other identity providers to authenticate on behalf of your AD B2C tenant. Additionally, B2C can federate to Azure AD allowing authentication of employees in an organization.
Setting Up Application Registrations
Azure B2C shares the concepts of Application Registrations with the standard Azure Active Directory. App Registrations with Azure AD B2C are used to take care of many common identity management tasks.
App registrations establish a unidirectional trust relationship between the defined application and the Microsoft identity platform. They also allow the administrators to control functions such as:
- Supported Account Types – Whether the application is used by users in a given organizational directory, will they allow other authentication providers, or if local accounts will be allowed.
- Redirect Settings – If the app needs to have the access token returned to a specific URI to process the next step of authentication and authorization.
- Certificates and Secrets – Used to verify that the application connecting to the Azure Identity platform is allowed to do so.
- Permissions, Token Scopes, and User Roles
In addition to the functions of the applications, administrators can also configure the registrations to fit the type of platform that will be hosting the application:
- Web
- Single-page application
- iOS/macOS
- Android
- Mobile and desktop applications
The Microsoft Authentication Library is an SDK with versions that support the most common code languages and frameworks, and it is the most common tool used to interface between the application code and the app registrations in the B2C.
MSAL has built in interfaces for you to pass the values of your App Registration Guids and Tenant Ids and will automatically handle the user’s authentications and token requests through the specified App registration.
The most common design patter is to configure one app registration per application code base. So on applications with a Front-End and a Backend components, each would receive their own registration. Permissions between the two can be configured using the “Expose an API” and “API Permissions” menus within the registrations’ pages.
Building User Journeys
One of the most important features of B2C is the ability to customize your users’ experiences throughout the common interactions and journeys they have with their account – such as signing in, signing up, changing their passwords, etc… Each of these User Journeys can be customized to present different layouts, logos, login steps, required user information, and more.
There are two options available when customizing the user journeys:
User Flows
- User flows are predefined, built-in, configurable policies that are provided by Azure Active Directory. These flows are built completely through the Azure Portal or via JSON Azure Resource Management templates. In general, these are the easiest to use and are recommended for all the most common scenarios. Scenarios where User Flows should be used include:
- Standard Sign In journeys with no custom fields on the “Sign In” pages (e.g., only username/password fields are possible in standard Sign In flows). “Sign Up” pages, in contrast, can include standard AND custom user attributes.
- Sign In/Sign Up processes with other trusted external Oauth providers such as Social Logins (Facebook, LinkedIn, etc.), other Active Directory instances (other Azure B2C or standard AAD tenants), or other Oauth/OpenId identity providers (Auth0, Okta, etc.)
- Sign In/Sign Up processes that call external APIs after federating with an identity provider during sign-up, before creating a user, or before including application claims in the users’ identity tokens. External API calls must match the standard format.
- Sign Up processes that collect common attributes to be collected from the consumer, such as first name, postal code, or country/region of residency. Additional attributes can be defined and added as required information in the sign up process as needed.
- Sign In/Sign Up processes that require Azure AD Multi-Factor Authentication (MFA)
- Sign In/Sign Up processes with custom logos, background screens, and styles
Custom Policies
- Custom policies are similar to User Flows in that they enable you to create your own user journeys, but they are intended for complex identity experience scenarios that are not supported by user flows. These policies are built using XML and provide extensibility for complex scenarios like:
- Sign In/Sign Up processes with enabled trusts through external SAML identity providers
- Sign In/Sign Up processes that need to collect custom fields or data during the “Sign In” process (e.g., adding “Nickname” as a required input every time the user signs in)
- Sign In/Sign Up processes that call external APIs after federating with an identity provider during sign-up, before creating a user, or before including application claims in the users’ identity tokens that require a custom request body format
- Sign In/ Sign Up processes that utilize first- and third-party multifactor authentication (MFA) challenges
For more details on the differences between user-flows and custom policies, view the Microsoft documentation comparing the two.
Now that we know the basics of implementing Azure B2C we will focus in future articles about some tips and tricks for implementing some of the common use-cases for this Azure offering.
