This chapter covers Azure AD B2C user flows and policies, a critical component for implementing customer identity and access management (CIAM) in Azure. On the AZ-204 exam, this topic appears in approximately 5-10% of questions, primarily in the Security domain (Objective 3.1). You will learn how user flows simplify authentication and authorization for external users, how to configure them via the Azure portal, and how they differ from custom policies. Mastering user flows is essential for building applications that require secure, customizable sign-in experiences without writing extensive custom code.
Jump to a section
Imagine a company with multiple retail stores, each with a different checkout process. One store requires only email and password, another requires social login with Facebook, and a third needs multi-factor authentication (MFA) and profile collection. Instead of building separate systems for each store, the company uses a single point-of-sale system with customizable forms. Each store manager selects a form template (a 'user flow') that defines the fields, validation rules, and steps (sign-in, sign-up, password reset). The system renders the appropriate form on the fly. When a customer checks out, the system processes the data according to the flow's policies—for example, sending an MFA code via SMS. If the flow is changed, all stores using that flow immediately see the new behavior. This is exactly how Azure AD B2C user flows work: they are pre-defined, configurable templates that control the identity experience for your applications. You create a flow for sign-up/sign-in, assign it to an app, and Azure AD B2C handles the UI and logic. The underlying policy engine enforces the rules, validates inputs, and issues tokens. Changing the flow updates the experience without code changes. Just as the checkout system uses the same backend but different front-end forms, Azure AD B2C user flows reuse the same identity platform but present different screens and behaviors based on the flow configuration.
What Are Azure AD B2C User Flows?
Azure AD B2C (Business-to-Consumer) is a customer identity access management (CIAM) service that enables you to customize and control how users sign up, sign in, and manage their profiles when using your applications. User flows are the simplest way to define these identity experiences. They are pre-built, configurable policies that you can create and modify through the Azure portal without writing code. Each user flow represents a complete authentication journey, such as sign-up/sign-in, profile editing, or password reset.
Why User Flows Exist
Before user flows, developers had to build custom authentication UIs and backend logic for each identity operation. This was error-prone and time-consuming. Azure AD B2C user flows abstract away the complexity by providing a visual designer where you select the steps you need (e.g., email verification, MFA, attribute collection) and the service renders the corresponding HTML pages. This allows you to quickly iterate on the user experience without touching your application code.
How User Flows Work Internally
When a user initiates a sign-in or sign-up operation, the application redirects the user to Azure AD B2C's endpoint. The request includes the user flow name (e.g., B2C_1_signupsignin1) as a query parameter. Azure AD B2C's policy engine then executes the steps defined in that user flow:
Orchestration Steps: The policy engine processes a sequence of orchestration steps. Each step corresponds to a technical profile (e.g., validate local account credentials, send MFA code, collect attributes). The steps are executed in order, and the flow can branch based on conditions (e.g., if social login is selected, skip local account validation).
Claims Exchange: During each step, claims (user attributes like email, display name, phone number) are collected and validated. Claims are stored in a temporary claims bag that persists across steps. For example, during sign-up, the email claim is collected, verified via a verification email, and then stored in the directory.
Token Issuance: After all steps complete successfully, Azure AD B2C issues an ID token (JWT) to the application. The token contains claims that you configured in the user flow (e.g., object ID, email, custom attributes). The application can then use this token to authenticate the user.
Key Components, Values, and Defaults
User Flow Name: Must start with B2C_1_ (e.g., B2C_1_signupsignin). The B2C_1_ prefix is required and indicates it's a user flow (as opposed to custom policy).
Built-in User Flow Types: Sign up and sign in (recommended for most apps), Profile editing, Password reset. You can also create a combined sign-up/sign-in flow.
Identity Providers: You can enable local accounts (email/password) or social identity providers (Google, Facebook, Microsoft, Amazon, LinkedIn, or any OpenID Connect provider). Default: local accounts only.
User Attributes: You can select which attributes to collect during sign-up (e.g., Given Name, Surname, Display Name, City). You can also create custom attributes via the Azure AD B2C blade.
Multifactor Authentication (MFA): Can be set to Off, Always on, or Conditional (based on risk). Default: Off.
Session Behavior: You can configure session lifetime (default: 24 hours), keep me signed in (default: disabled), and single sign-on (SSO) across apps.
Token Lifetime: Access token lifetime (default: 1 hour), ID token lifetime (default: 1 hour), refresh token lifetime (default: 14 days), sliding window (default: 90 days).
Page UI Customization: You can upload custom HTML/CSS templates to brand the authentication pages. The templates must be hosted on a publicly accessible HTTPS endpoint with CORS enabled.
Configuration and Verification Commands
User flows are configured entirely through the Azure portal. There are no CLI commands to create or modify user flows directly, but you can manage them using Azure PowerShell or Azure CLI with the AzureADB2C module. For example:
# Connect to Azure AD B2C tenant
Connect-AzureAD -TenantId "yourtenant.onmicrosoft.com"
# Get all user flows
Get-AzureADB2CUserFlow
# Create a new sign-up/sign-in user flow
New-AzureADB2CUserFlow -Name "B2C_1_signupsignin" -UserFlowType "SignUpOrSignIn" -LocalAccountsOnly $trueTo verify the flow, you can use the Run user flow feature in the portal, which opens a new browser tab simulating the end-user experience. This is essential for testing before deployment.
Interaction with Related Technologies
Custom Policies: User flows are built on top of the same Identity Experience Framework (IEF) as custom policies but are limited to a fixed set of options. Custom policies offer full flexibility via XML configuration files but require deeper expertise. User flows are recommended for most scenarios; custom policies are for complex scenarios not supported by user flows.
Application Registration: Each application that uses Azure AD B2C must be registered in the Azure AD B2C tenant. The user flow is associated with the application via the User flows blade in the app registration.
Azure AD B2C Graph API: You can programmatically manage user flows using the Microsoft Graph API for Azure AD B2C (beta endpoint).
Conditional Access: Azure AD B2C supports Conditional Access policies that can be applied to user flows to enforce MFA or block access based on risk.
Exam-Relevant Details
The exam expects you to know the difference between user flows and custom policies: user flows are for standard scenarios, custom policies for advanced customization.
You must understand the B2C_1_ naming convention.
Know the default token lifetimes and session settings.
Be aware that user flows can be versioned (e.g., v1, v2). The exam may test that v2 user flows support more features like custom attributes and conditional access.
Remember that user flows are tenant-wide resources; you can assign multiple applications to the same user flow.
Summary of Internal Mechanism
At a high level, Azure AD B2C user flows are a simplified interface over the Identity Experience Framework. When a user accesses an application, the application redirects to the Azure AD B2C endpoint with the user flow name. The IEF engine reads the user flow definition (stored as an XML policy in the tenant) and executes the orchestration steps. Each step may call technical profiles that interact with identity providers, validate claims, or send emails. After successful execution, a token is issued. The entire process is stateless from the application's perspective; the state is managed by Azure AD B2C via cookies and the user's browser.
Create an Azure AD B2C Tenant
First, you need an Azure AD B2C tenant. This is a separate directory from your Azure AD tenant. In the Azure portal, search for 'Azure AD B2C' and create a new tenant. You'll need to provide a tenant name (e.g., contosob2c) and a domain name (e.g., contosob2c.onmicrosoft.com). The tenant is where all users, apps, and policies reside. This step is a prerequisite for any B2C work. On the exam, you might be asked how to create a B2C tenant or to identify that B2C tenants are different from regular Azure AD tenants.
Register Your Application
In the Azure AD B2C tenant, register the application that will use the user flow. Go to 'App registrations' and create a new registration. Provide a name, select supported account types (typically 'Accounts in any identity provider or organizational directory'), and set the redirect URI (e.g., https://jwt.ms for testing). Note the Application (client) ID — you'll need it when configuring the user flow. This step ties the application to the B2C tenant so that tokens are issued for that app.
Create a User Flow
Navigate to 'User flows' in the Azure AD B2C blade and click 'New user flow'. Select the flow type (e.g., 'Sign up and sign in'). Give it a name that starts with B2C_1_ (e.g., B2C_1_signupsignin). Then configure the identity providers (local accounts, social providers), user attributes to collect, MFA settings, and session behavior. After creation, the flow is stored as a policy in the tenant. You can edit it later, but some changes may require a new version.
Associate the User Flow with the Application
In the user flow overview page, under 'Applications', select the application you registered. This step is crucial — without it, the application cannot use the user flow. You can associate multiple applications with the same user flow. The association tells Azure AD B2C which user flow to invoke when the application redirects users for authentication. The application passes the user flow name in the request (e.g., as the `p` parameter in the URL).
Test the User Flow
Use the 'Run user flow' feature in the portal to simulate the end-user experience. This opens a new browser window where you can sign up or sign in. Verify that the correct attributes are collected, MFA works if configured, and the token is returned. You can inspect the token using a tool like jwt.ms. This step ensures the flow works as expected before deploying to production. On the exam, you might be asked how to test a user flow or what the Run user flow feature does.
Update Application Code to Use the User Flow
In your application code, configure the authentication library (e.g., MSAL) to redirect users to the Azure AD B2C endpoint with the user flow name. For example, in a .NET application, you set the `Authority` to `https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/B2C_1_signupsignin`. The `b2clogin.com` domain is preferred over `login.microsoftonline.com` to avoid cookie sharing with enterprise Azure AD. The application must handle the token response and validate the token.
Enterprise Scenario 1: E-Commerce Platform with Social Login
A large e-commerce company wants to allow customers to sign in using Google or Facebook. They create a sign-up/sign-in user flow with both local accounts and social identity providers enabled. They configure the user flow to collect the user's email and name, and enable MFA for high-value transactions. In production, they have millions of users. The user flow handles the redirects to Google/Facebook, processes the returned tokens, and maps the social account claims to the B2C user profile. The company uses custom page templates to match their brand. A common misconfiguration is forgetting to set the correct redirect URIs in the social provider's developer console, causing login failures. They also need to ensure that the B2C tenant is in the same region as their users to minimize latency. Performance is generally good, but during peak sales, they may see throttling; they can request quota increases from Microsoft.
Scenario 2: SaaS Application with Multi-Tenant B2C
A SaaS provider builds a multi-tenant application where each customer gets a subdomain (e.g., customer1.app.com). They want to use a single Azure AD B2C tenant for all customers but differentiate users per tenant. They use user flows with custom attributes to store a tenant ID. During sign-up, the user flow collects the tenant ID via a hidden field or URL parameter. The application then uses the tenant ID to route users to the correct tenant database. They also use password reset user flows. A challenge is ensuring that the user flow's attribute collection matches the application's requirements. If the user flow collects attributes that are not needed, it adds friction. They also need to handle user migration from legacy systems, often by seeding users via Graph API and then using the user flow for new sign-ups.
Scenario 3: Mobile App with Biometric Authentication
A bank's mobile app uses Azure AD B2C for customer authentication. They want to support fingerprint or face ID after initial login. They use a sign-up/sign-in user flow for the initial authentication, then the app uses the refresh token to obtain new tokens without re-prompting. The user flow is configured with a short session lifetime (e.g., 1 hour) and a longer refresh token lifetime (e.g., 90 days). For high-security operations, they use a separate user flow that requires MFA. The mobile app uses MSAL for Android/iOS. A common issue is that if the refresh token expires, the user must re-authenticate, which can be frustrating. They mitigate this by using the 'Keep me signed in' feature. Misconfiguring token lifetimes can lead to security gaps or poor user experience.
What AZ-204 Tests on This Topic
The AZ-204 exam covers Azure AD B2C user flows under objective 'Implement user authentication and authorization' (Subobjective 3.1). Specific skills measured include:
Create and configure user flows.
Associate user flows with applications.
Understand the difference between user flows and custom policies.
Configure token lifetimes and session behavior.
Enable social identity providers.
Customize the user interface.
Common Wrong Answers and Why Candidates Choose Them
Choosing custom policies over user flows for simple scenarios: Many candidates think custom policies are always better because they offer more control. However, the exam expects you to choose user flows for standard sign-up/sign-in scenarios because they are easier to configure and maintain. Custom policies are only needed for complex orchestration or integration.
Forgetting the B2C_1_ prefix: The exam may present a user flow name without the prefix (e.g., 'signupsignin') and ask if it's valid. Candidates might think it's fine, but Azure AD B2C requires the prefix. The correct answer is that the name must start with B2C_1_.
Using login.microsoftonline.com instead of b2clogin.com: The exam may test which endpoint to use. Many candidates default to login.microsoftonline.com, but for Azure AD B2C, the recommended endpoint is b2clogin.com to avoid cookie sharing with enterprise Azure AD. The exam expects you to know this.
Confusing user flows with custom policies in terms of UI customization: Both support HTML/CSS customization, but user flows have a simpler customization interface. The exam might ask which method allows full control over the UI; the answer is custom policies, but user flows still allow significant customization.
Specific Numbers and Terms That Appear on the Exam
Default token lifetimes: access token 1 hour, ID token 1 hour, refresh token 14 days (sliding window 90 days).
Session lifetime default: 24 hours.
User flow naming: must start with B2C_1_.
The 'Run user flow' feature is used for testing.
Supported social providers: Google, Facebook, Microsoft, Amazon, LinkedIn.
Custom attributes must be created in the Azure AD B2C blade under 'User attributes'.
Edge Cases and Exceptions
If you change a user flow after users have started sessions, existing sessions are not affected; changes apply to new authentications.
User flows cannot be deleted if they are associated with an application; you must remove the association first.
Custom policies can reference user flows? No, they are separate.
The exam may test that user flows support versioning (v1, v2). v2 is the latest and supports more features.
How to Eliminate Wrong Answers
Focus on the core scenario: if the question describes a standard sign-up/sign-in experience with social providers, the answer is user flows. If it mentions complex claims transformation, custom orchestration, or integration with external APIs, the answer is custom policies. Also, always check the naming convention: if a user flow name doesn't start with B2C_1_, it's invalid. For endpoints, b2clogin.com is the correct choice for B2C.
User flows are pre-built, configurable authentication policies for Azure AD B2C, named with the B2C_1_ prefix.
Default token lifetimes: access token 1 hour, ID token 1 hour, refresh token 14 days (sliding window 90 days).
Session lifetime defaults to 24 hours; keep me signed in is disabled by default.
Use b2clogin.com for endpoints, not login.microsoftonline.com.
User flows support social identity providers: Google, Facebook, Microsoft, Amazon, LinkedIn.
Custom policies are for advanced scenarios; user flows cover most needs.
Associate user flows with applications; one flow can serve multiple apps.
Test user flows using the 'Run user flow' feature in the portal.
These come up on the exam all the time. Here's how to tell them apart.
User Flows
Easier to configure via portal UI
Limited to predefined options
Recommended for standard scenarios
Name must start with B2C_1_
Faster to set up and maintain
Custom Policies
Configured via XML files
Full control over orchestration and claims
Required for complex scenarios
No naming convention requirement
Steeper learning curve
Mistake
Azure AD B2C user flows are the same as Azure AD conditional access policies.
Correct
User flows define the authentication journey (sign-up, sign-in, password reset). Conditional access policies are separate and can be applied to user flows to enforce MFA or block access based on risk. They are not the same.
Mistake
You can use any domain for the B2C endpoint, such as login.microsoftonline.com.
Correct
The recommended endpoint is b2clogin.com (e.g., contoso.b2clogin.com). Using login.microsoftonline.com can cause cookie sharing issues with enterprise Azure AD tenants. The exam expects b2clogin.com.
Mistake
User flows can be modified after creation without any limitations.
Correct
You can edit a user flow after creation, but some changes (like adding new identity providers) may require creating a new version. Existing sessions are not affected by changes.
Mistake
Custom policies are always better than user flows because they offer more flexibility.
Correct
Custom policies are more flexible but also more complex. For standard scenarios, user flows are recommended because they are easier to configure and maintain. The exam favors user flows for typical requirements.
Mistake
User flows cannot be used with mobile applications.
Correct
User flows work with any application type (web, mobile, desktop) that can redirect to an HTTPS endpoint. Mobile apps use MSAL to handle the authentication flow.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In the Azure portal, navigate to your Azure AD B2C tenant, select 'User flows' under 'Policies', and click 'New user flow'. Choose the flow type (e.g., Sign up and sign in), provide a name starting with B2C_1_, and configure identity providers, attributes, MFA, and session settings. After creation, associate it with your application. For example, a simple sign-up/sign-in flow might be named B2C_1_signupsignin.
User flows are pre-built, configurable templates for common identity scenarios, configured via the portal. Custom policies are XML-based, fully customizable policies that allow complex orchestration and integration with external systems. User flows are recommended for most applications; custom policies are for scenarios that require advanced customization not supported by user flows.
Yes, user flows work with mobile apps. The app uses MSAL (Microsoft Authentication Library) to redirect the user to the B2C endpoint with the user flow name. The user flow handles authentication and returns tokens to the app. Mobile apps can also use system browsers or embedded web views.
You can upload custom HTML/CSS templates in the user flow's 'Page layouts' section. The templates must be hosted on a publicly accessible HTTPS endpoint with CORS enabled. You can customize each step (e.g., sign-in, sign-up, MFA) independently. Alternatively, use custom policies for full control.
Default lifetimes: Access token – 1 hour, ID token – 1 hour, Refresh token – 14 days (with sliding window of 90 days). You can modify these in the user flow's 'Token lifetime' settings. For example, you might shorten access token lifetime for higher security.
In the Azure portal, open the user flow and click 'Run user flow'. This opens a new browser tab that simulates the end-user experience. You can walk through sign-up, sign-in, and other steps. Use a tool like jwt.ms to inspect the returned token. This helps verify configuration before production deployment.
Yes, you can create multiple user flows (e.g., one for sign-up/sign-in, another for password reset) and associate them with the same application. The application must specify which user flow to use when redirecting users. This allows different authentication experiences for different scenarios.
You've just covered Azure AD B2C User Flows and Policies — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?