Azure AD B2C Tutorial

by

A regional insurance company asked me to fix its customer portal login. Customers had to create a username and password in a custom database, and the help desk reset about 200 passwords a week. Worse, the passwords sat in a table that a contractor had exported to a spreadsheet. We needed a real customer identity service, and fast.

That is the problem this Azure AD B2C tutorial solves. Azure Active Directory B2C is a customer identity service. It handles sign-up, sign-in, password reset, and social logins for apps used by people outside your company. You stop storing passwords yourself, and your app receives a signed token instead.

There is one important fact up front. Microsoft stopped selling Azure AD B2C to new customers on May 1, 2025, and says it will support existing customers until at least May 2030. I will show you the full setup for existing tenants, explain the Entra External ID successor, and help you decide what to build today.

Know the Azure AD B2C Status Before You Build

Check the service status first, because it changes your plan. Microsoft’s FAQ states that Azure AD B2C is no longer available for new customers as of May 1, 2025, and that current customers can keep using it. It also says Azure AD B2C P2 was discontinued on March 15, 2026, so new and existing tenants rely on the P1 tier. Microsoft says it will support the product until at least May 2030.

The successor is Microsoft Entra External ID, which is where Microsoft is putting new feature work. That leaves three practical paths:

  • You have an existing B2C tenant: Keep operating it, and use this tutorial to maintain or extend it.
  • You are starting a new customer app: Evaluate Entra External ID first, since new features are going there.
  • You must stay on B2C for a project: Confirm in the Azure portal that you can create a tenant, and plan a migration before 2030.

Many of the concepts below transfer to External ID, including app registrations, tokens, and identity providers. The portal screens and policy options differ, so test before you assume parity.

Pro Tip: In my experience, I start every identity project with a one-page decision note: which product, why, and the migration date. It prevents a surprise redesign in year three.

Understand How Azure AD B2C Works

A tenant is a dedicated instance of an identity directory that holds your users and app registrations. If you want the background, read what a tenant in Azure is. A B2C tenant is separate from your company’s workforce directory. Your employees sign in with their work accounts in one tenant, and your customers sign in through the B2C tenant.

That separation matters for security. If a customer account is compromised, it does not live next to your employee mailboxes and admin roles. To compare these models, see Azure AD B2B vs. B2C. The short version is that B2B invites partners into your workforce tenant, and B2C serves public customers.

Here are the pieces you will configure:

  • App registration: Tells the tenant that your app exists and where to send tokens.
  • User flow: A pre-built sign-up or sign-in experience, such as “sign up and sign in.”
  • Identity provider: A source of identities, such as local email accounts or a social login.
  • Token: A signed JSON Web Token (JWT) that proves who the user is. Your app validates it.
  • Custom policy: An advanced XML-based option for complex journeys that user flows cannot handle.Pro Tip: I explain B2C to project managers with one sentence: “We rent the login box, and we keep the customer experience.” It sets the right expectations on what the service does.

Plan the Architecture Before You Click

A good B2C design starts with requirements, not the portal. Ask these questions with the business owner:

  • Which sign-in methods do customers expect: email, phone, Google, Apple?
  • Do you need multifactor authentication (MFA) for all users or only high-risk actions?
  • Which user attributes do you collect, such as name, country, or postal code?
  • Which apps will use the tenant, and are they web, single-page, or mobile?
  • Where must customer data live for legal reasons?

The last question is important. When you create a B2C tenant, you choose a data residency location, such as United States. You cannot change it later, so choose with legal and compliance involved. Also decide the subscription and resource group now.

A B2C tenant is linked to an Azure subscription for billing, and keeping it in a dedicated Azure resource group simplifies cost tracking and access control. Review these Azure Policy best practices if your organization enforces tagging or location rules.

For cost, B2C is priced by monthly active users, not by compute. The pricing model has tiers and free allowances that Microsoft adjusts, so confirm current rates for your region and agreement instead of relying on a blog. See also Azure AD pricing for the general licensing background.

Pro Tip: I tag the B2C resource with environment and owner tags on day one. Identity costs follow active users, and finance will ask which product line caused a jump.

Step 1: Create the Azure Resources

If your organization can still create a tenant, begin with the resource group and tenant. This walkthrough on how to create an Azure AD B2C tenant shows the portal screens. Sign in with the CLI first, as explained in this Azure CLI login guide.

az group create \
  --name rg-customer-identity-prod \
  --location eastus \
  --tags environment=prod workload=customer-portal owner=identity-team

This command creates a resource group named rg-customer-identity-prod in the East US region, giving your identity resources a shared management boundary. The --tags parameter adds labels that make cost reviews easier.

Next, create the B2C directory resource. The portal is the usual path, but you can deploy it with a template. The tenant name becomes part of a domain like <tenant-name>.onmicrosoft.com, and it cannot be changed, so pick a name that you can live with.

param tenantName string
param countryCode string = 'US'
param location string = 'United States'

resource b2cTenant 'Microsoft.AzureActiveDirectory/b2cDirectories@2023-05-17-preview' = {
  name: '${tenantName}.onmicrosoft.com'
  location: location
  sku: {
    name: 'PremiumP1'
    tier: 'A0'
  }
  properties: {
    createTenantProperties: {
      displayName: tenantName
      countryCode: countryCode
    }
  }
}

This Bicep resource creates a B2C directory with the P1 tier, the display name you pass in, and a country code that sets data residency. The values come from parameters, so dev and prod can use different tenants without editing the file. Because the API version is a preview, check it against current documentation before deployment. Repeatable templates cut manual errors, like mistyping a tenant name in production.

Use separate tenants for development and production. A shared tenant makes it too easy to break live sign-in while testing a new policy.

Pro Tip: I keep one B2C tenant for dev and one for prod, and I never reuse the app registrations between them. It costs a little more to maintain, but it removes a whole class of outage.

Step 2: Register Your Application

An app registration tells the tenant which app can request tokens and where to send them. Open your B2C tenant, select App registrations, and choose New registration. For a deeper explanation, read this guide on Azure app registration.

Use these settings for a typical web app:

  1. Enter a clear name, such as customer-portal-prod.
  2. Under supported account types, choose accounts in any identity provider or organizational directory for authenticating users with user flows.
  3. Add a redirect URI of type Web. For testing, Microsoft’s tutorial uses the JWT decoding site, but use your real HTTPS callback for production.
  4. Grant admin consent for the openid and offline_access permissions.
  5. Record the Application (client) ID.

A redirect URI is the exact address where the tenant sends the user and token after sign-in. It must match your app’s setting character for character. A trailing slash or an HTTP/HTTPS mismatch will fail, and the error is covered in this article on the Azure AD reply URL.

If your app uses the implicit flow while you test, you must enable ID tokens on the Authentication page. Without it, you will see the error explained in response_type id_token is not enabled for the application. Prefer the authorization code flow with PKCE for single-page and mobile apps, since the implicit flow is older and less secure.

For web apps that use a client secret, learn where values come from in this guide on getting a client ID and client secret in the Azure portal. Never paste a client secret into source code or a shared spreadsheet.

Pro Tip: I set client secret expiry reminders in the team calendar the day I create a secret. A secret that silently expires has taken down more customer logins than any attack I have seen.

Step 3: Create a Sign-Up and Sign-In User Flow

A user flow is a configurable journey that handles sign-up, sign-in, password reset, or profile edits. They are the fastest route to a working login, and I recommend them unless you need unusual logic.

In the B2C tenant, go to User flows, select New user flow, and choose Sign up and sign in. Then:

  1. Select the Recommended version.
  2. Name the flow, for example signupsignin1. Azure adds a B2C_1_ prefix.
  3. Choose Email signup as the identity provider.
  4. Select the attributes to collect and the claims to return in the token, such as display name and country.
  5. Select Create.

Be selective about attributes. Each extra field lowers sign-up completion and increases the personal data you must protect. Collect only what the business needs on day one, and gather the rest later through profile editing.

Then run the flow from the portal and select your registered app. You should see a sign-up page, email verification, and a token returned to your redirect address. Decode the token and check the claims. Try three cases: a new user, a returning user, and a wrong password.

Add multifactor authentication

MFA reduces account takeover, and it is worth turning on for any app that holds money, health, or personal data. Read what MFA is if your team is new to it. In the user flow’s properties, choose the MFA method and enforcement. Using “conditional” enforcement applies MFA only to risky sign-ins, which gives a smoother experience. Test the recovery path too, because users who lose a phone will call support.

Pro Tip: I always ask the help desk to try the password reset flow before launch. They find confusing wording in ten minutes that developers miss in ten days.

Step 4: Connect the Application

Your app must redirect users to B2C and validate the returned token. Use a maintained library, such as the Microsoft Authentication Library (MSAL) or the Microsoft Identity Web package for ASP.NET Core. Do not write your own JWT validation.

This appsettings.json pattern keeps secrets out of the file:

json{
  "AzureAdB2C": {
    "Instance": "https://<tenant-name>.b2clogin.com",
    "Domain": "<tenant-name>.onmicrosoft.com",
    "ClientId": "<application-client-id>",
    "SignUpSignInPolicyId": "B2C_1_signupsignin1",
    "CallbackPath": "/signin-oidc"
  }
}

The client ID is not a secret, so it can sit in configuration. The Instance uses the b2clogin.com domain, and the policy ID names your user flow. CallbackPath must match the redirect URI you registered. Anything secret, such as a client secret or certificate password, belongs in Azure Key Vault, a service for storing secrets, keys, and certificates. Learn the options in these Azure Key Vault best practices.

When you host the app in Azure App Service, give it a managed identity, an identity Azure manages for the app, and grant it permission to read secrets from Key Vault. Here is what a managed identity in Azure is, and you can follow this guide to create an Azure web app as the host.

az webapp identity assign \
  --name <web-app-name> \
  --resource-group rg-customer-identity-prod

This command turns on a system-assigned managed identity for the web app. Then grant that identity the Key Vault Secrets User role at the vault scope, using Azure RBAC. Here is the basic idea of what RBAC is, and this comparison of Azure roles vs. Entra roles clarifies which permissions control Azure resources and which control directory objects.

If your API sits behind the app, validate the access token’s audience and scope on every request. A common mistake is to check only that the token is signed. You must also check that it was issued for your API.

Pro Tip: I once found an API that accepted tokens issued for a completely different app, because the audience check was missing. I now write a failing test for a wrong-audience token on every project.

Step 5: Extend the Flow With an API Connector

Sometimes you need custom logic during sign-up, such as checking a customer number against a CRM or blocking disposable email domains. An API connector calls a REST endpoint that you host. Azure Functions fits well here, because it is small and cheap. See how to create an API with Azure Functions.

Treat that endpoint like a production API. Require authentication, return fast, and set a short timeout. Sign-up waits for your response, so a slow function leads to abandoned registrations. On the Consumption plan, cold starts can add delay, so test the worst case.

Protect the connector with basic authentication or a client certificate, and store the credentials in Key Vault. Do not leave the function open to the internet without a check, because anyone could call it and learn about your customers.

Secure and Govern the Tenant

Identity systems are high-value targets, so apply least privilege to your admins. Give each administrator only the role they need, avoid permanent Global Administrator accounts, and review role assignments every quarter. Use a break-glass account stored securely for emergencies, and monitor it for any sign-in.

Add these controls:

  • Conditional Access: In B2C, use policies and risk-based rules to challenge suspicious sign-ins. To learn the basics, see how to