Azure AD B2C: Fix Setup Errors & Config Problems
Why This Is Happening
You've been staring at the Azure portal for two hours. Your Azure AD B2C tenant is configured, your app is registered, and yet your users still can't sign in. Maybe you're getting a generic AADB2C90011 error, or your redirect URI keeps getting rejected, or the token your API receives simply doesn't contain the claims you expected. I've seen this exact situation on dozens of projects , and the maddening part is that Microsoft's error messages rarely tell you what actually went wrong.
Here's the root of it. Azure AD B2C is a specialized customer identity access management (CIAM) service built on the same underlying technology as Microsoft Entra ID, but it behaves very differently. It's designed to handle millions of consumer users and billions of authentications per day , but that scale and power come with a configuration surface that is genuinely complex. A single misconfigured redirect URI, a missing API scope, or a user flow that doesn't match your token request will silently break the whole thing.
The service handles OpenID Connect, OAuth 2.0, and SAML protocols. That's three different auth paradigms, each with their own quirks inside the B2C context. Most developers hit problems at the intersection of these: they expect B2C to behave like a standard Entra ID tenant, wire up their MSAL client expecting vanilla OAuth behavior, and then wonder why access tokens don't arrive or why the sign-in page looks wrong.
Configuration errors fall into a few predictable buckets. First, application registration mismatches, your redirect URIs, grant types, or API permission scopes don't line up between your app and the tenant. Second, user flow and custom policy conflicts, especially when teams inherit a tenant setup by someone else and don't realize a custom policy is overriding a built-in user flow. Third, token claim issues, the claims returned by B2C depend entirely on what you configured in your user flow or policy, and this trips up nearly everyone at least once. Fourth, social and work identity provider setup errors, OAuth apps registered with Google, Facebook, or an enterprise IdP that have expired secrets or misconfigured callback URLs.
I know this is frustrating, especially when it's blocking a production launch or a demo that's happening in four hours. The good news: almost every Azure AD B2C error is traceable and fixable. Let's work through it systematically.
The Quick Fix, Try This First
Before you go deep into custom policies or call Microsoft Support, run through this checklist. In my experience, roughly 60% of Azure AD B2C sign-in failures trace back to one of these three things, and you can check all of them in under ten minutes.
Step 1, Verify your redirect URI exactly. Go to your Azure portal, navigate to Azure AD B2C → App registrations → [Your App] → Authentication. Look at the redirect URIs listed. Now look at what your application is actually sending in the authorization request. These must match character-for-character, trailing slashes included. https://myapp.com/callback and https://myapp.com/callback/ are treated as different URIs. This catches more problems than anything else.
Step 2, Check your user flow is published and selected correctly. Go to Azure AD B2C → User flows. Open the user flow your application references. Make sure it's in a Enabled state. Then verify that the exact user flow name in your code (the p= parameter in your authorization URL) matches what's shown in the portal, including the version suffix like _v2.
Step 3, Confirm your application's client secret hasn't expired. Go to App registrations → [Your App] → Certificates & secrets. Check the expiry date on your client secret. An expired secret produces a generic authentication failure that looks identical to a misconfiguration. If it's expired or expiring within a week, generate a new one immediately and update it in your application settings.
If those three checks don't resolve it, the issue is deeper, keep reading.
&prompt=login to your authorization URL to force a fresh sign-in and bypass any cached session state. Cached sessions mask a surprising number of configuration errors during development, you think it's working because the old session carries through, but the real token request is broken.
Application registration is where most Azure AD B2C journeys go wrong. The portal flow looks simple, but there are a handful of settings that have non-obvious implications for how authentication and authorization work downstream.
In the Azure portal, go to Azure AD B2C → App registrations → New registration. Give it a name that distinguishes it clearly from any Entra ID apps in the same portal, this matters when you're debugging and switching contexts. Under Supported account types, select "Accounts in any identity provider or organizational directory (for authenticating users with user flows)". This is the B2C-specific option, and selecting one of the Entra ID-scoped options instead is a common mistake.
For redirect URIs, add every URI your application will use across all environments, development, staging, production. For local development with MSAL.js or MSAL.NET, you'll typically need something like http://localhost:3000/ or http://localhost:5000/signin-oidc. For native mobile apps using MSAL iOS or Android, use the MSAL redirect URI format:
msauth.[your.bundle.id]://authOnce the app is registered, go to Authentication → Advanced settings and make sure Allow public client flows is set correctly for your app type. For single-page apps and native mobile apps using authorization code + PKCE, this should typically be enabled. For confidential web apps and APIs, leave it off.
If it worked, navigating to your authorization endpoint with the correct parameters should redirect you to your B2C-hosted sign-in page without any redirect_uri or client_id errors.
Azure AD B2C user flows are pre-built, configurable authentication journeys. Getting the right one set up, and set up correctly, is what determines what your sign-in page looks like, what claims come back in the token, and what identity providers your users can choose from.
Go to Azure AD B2C → User flows → New user flow. For most consumer-facing applications, start with Sign up and sign in (Recommended), this handles both new registrations and returning sign-ins in a single flow. Select the Recommended version when prompted; the older versions are kept for backward compatibility but lack newer features.
On the configuration page, under Identity providers, you can add local accounts (email + password), phone sign-in, and any social or enterprise IdPs you've already configured. Under User attributes and token claims, this is the critical section most developers overlook: you must explicitly check the claims you want returned in the token here. If email, given_name, or objectId aren't checked under Return claim, they won't appear in the token, even if the data exists in the user's profile.
After creating the flow, test it immediately using the Run user flow button in the portal. Select your registered application, provide a valid reply URL, and click Run. The portal will show you the exact token claims returned, which is invaluable for verifying your claim configuration before touching your application code.
If the test flow returns a token and your application still doesn't receive the expected claims, compare the exact user flow name in your auth URL's p= parameter against the flow name shown in the portal.
Microsoft recommends MSAL, the Microsoft Authentication Library, for any application type connecting to Azure AD B2C. There's MSAL.NET for .NET apps, MSAL.js for web and SPA apps, MSAL Python, MSAL Java, and MSAL for iOS and Android. Using a non-MSAL library against B2C is possible but introduces a class of subtle protocol-handling bugs that simply don't exist with MSAL.
The most important Azure AD B2C-specific configuration when setting up MSAL is the authority URL. This is not the same as a standard Entra ID authority. It takes this form:
https://[your-tenant-name].b2clogin.com/[your-tenant-name].onmicrosoft.com/[your-user-flow-name]For example, with MSAL.js you'd configure it like this:
const msalConfig = {
auth: {
clientId: "your-application-client-id",
authority: "https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/B2C_1_signupsignin",
knownAuthorities: ["mytenant.b2clogin.com"],
redirectUri: "https://myapp.com/callback"
}
};The knownAuthorities field is easy to miss but critically important, without it, MSAL will refuse to use the B2C authority because it doesn't match the standard Entra ID authority pattern. This produces an untrusted_authority error that's confusing if you haven't seen it before.
For MSAL.NET in ASP.NET Core, the equivalent goes in your appsettings.json under an AzureAdB2C section, and you call AddMicrosoftIdentityWebAppAuthentication in your startup with the AzureAdB2C configuration key.
Once configured correctly, your app's sign-in call should redirect cleanly to the B2C sign-in page, and the token exchange should complete without errors.
If your Azure AD B2C setup involves a backend API, which it usually does, there's a separate registration and configuration path for it, and this is where access token errors live. The symptom is usually that your frontend gets a token but your API rejects it with 401 Unauthorized, or the token validation fails with a signature or audience mismatch.
Register your API as a separate application in Azure AD B2C → App registrations → New registration. After registering it, go to Expose an API → Add a scope. Define at least one scope, for example read or access_as_user. The full scope URI will look like:
https://[your-tenant].onmicrosoft.com/[your-api-app-id-uri]/readNow go back to your frontend application registration → API permissions → Add a permission → My APIs, and add the scope you just created. This wires the two registrations together.
In your MSAL client configuration, you must request this scope explicitly when acquiring access tokens:
const tokenRequest = {
scopes: ["https://mytenant.onmicrosoft.com/myapi/read"]
};On the API side, your token validation middleware needs to check the aud (audience) claim matches your API's application ID, and the tfp or acr claim matches your user flow name. In ASP.NET Core Web API, the AddMicrosoftIdentityWebApiAuthentication extension handles this automatically when configured with the AzureAdB2C section.
After this, calling your API with the access token in the Authorization: Bearer [token] header should return 200 instead of 401.
One of Azure AD B2C's most appealing features is letting users sign in with Google, Facebook, Microsoft personal accounts, or a corporate SAML/OIDC provider. But the callback chain between B2C and external identity providers introduces its own set of failure points.
To add a social provider, go to Azure AD B2C → Identity providers → Add. Select your provider (e.g., Google). You'll need to provide a Client ID and Client secret from the external provider's developer console. For Google, this comes from Google Cloud Console → APIs & Services → Credentials. For Facebook, it's from the Facebook Developer portal.
The most common failure here is the callback URL mismatch. When you register your OAuth app with the external provider, you must set the callback URL to exactly:
https://[your-tenant].b2clogin.com/[your-tenant].onmicrosoft.com/oauth2/authrespIf you're using a custom domain, replace the B2C login domain with your custom domain in that callback URL. Getting this wrong produces an invalid_redirect_uri error from the external provider, which surfaces in B2C as a generic sign-in failure, not the most helpful error message.
For enterprise identity providers using SAML or OIDC, the setup is done through Custom policies rather than the built-in user flows. This is a significantly more involved process, you'll work with XML-based Trust Framework policies. If you're going this route, the official B2C GitHub samples repository has working starter templates that will save you hours of troubleshooting.
After adding the provider, go back to your user flow, edit it, and explicitly add the new identity provider under Identity providers. It won't appear on the sign-in page automatically, you have to add it to each user flow that should show it.
Advanced Troubleshooting
When the basic steps don't get you there, it's time to go deeper. These are the tools and techniques I use when Azure AD B2C issues resist the standard fixes.
Azure AD B2C Audit Logs. In the Azure portal, go to Azure AD B2C → Monitoring → Audit logs. Filter by Service: B2C and Date: Last 1 hour. Every user sign-in attempt, token issuance, and policy execution generates an audit event here. Look for events with Activity: Issue an id_token or Activity: Validate Authorization Code and check the Status column. Failed events include a reason that's far more specific than what the end user sees, error codes like AADB2C90080 (grant expired), AADB2C90019 (invalid client), or AADB2C90236 (consent required) tell you exactly where in the flow things broke.
Application Insights Integration. For production environments, connect Azure Application Insights to your B2C tenant for persistent log retention and query capabilities. In the portal, go to Azure AD B2C → Monitoring → Diagnostic settings → Add diagnostic setting. Send AuditLogs and SignInLogs to your Application Insights resource. Once connected, you can write KQL queries like:
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription
| order by TimeGenerated descCustom Policy Debugging. If you're using custom policies (the XML-based Identity Experience Framework), enable developer mode in your custom policy by adding <Mode>Development</Mode> inside your <TrustFrameworkPolicy> element during testing. This surfaces detailed error messages in the browser instead of generic failure pages. Never ship with this enabled, it exposes internal policy details.
Token Validation in jwt.ms. Microsoft maintains a token inspector at jwt.ms. Paste any Azure AD B2C token there to decode the claims. This is the fastest way to verify whether the aud, iss, tfp, and your custom claims are present and correctly formatted. Comparing the decoded token against what your application expects resolves a huge number of "it authenticated but my app is broken" scenarios.
CORS Errors in SPA Applications. If you're building a single-page app with MSAL.js and seeing CORS errors during token requests, check that your SPA redirect URIs are registered under the Single-page application platform in App registrations, not just the Web platform. B2C handles these differently, SPA redirect URIs use authorization code flow with PKCE, while Web platform URIs are for confidential clients. Mixing them up produces CORS failures on the token endpoint.
If you're seeing consistent authentication failures that don't match any documented error code, if your tenant is returning 5xx errors from the B2C endpoints, or if Audit Logs show errors but contain no meaningful reason code, that's when to escalate. Also escalate if you suspect tenant-level provisioning issues, or if you've inherited a B2C tenant that may have been set up with conflicting custom policies you can't fully audit. Open a support case through Microsoft Support, and include your correlation IDs from the Audit Logs, these cut response time dramatically by letting Microsoft engineers trace your exact request through their infrastructure.
Prevention & Best Practices
Most Azure AD B2C fires are preventable. Here's what the teams with smooth B2C deployments do differently from the ones who are constantly firefighting.
Treat user flows as versioned artifacts. Don't edit a live user flow in place, clone it first, make your changes to the clone, test it thoroughly with the Run user flow tool, then update your application to point to the new version. This keeps a working rollback path open at all times. Label your user flows clearly: B2C_1_signup_signin_v3 is more useful than B2C_1_signup_signin_new_copy at 2 AM during an incident.
Set up client secret rotation before it becomes urgent. Client secrets in Azure AD B2C app registrations have a maximum expiry of 24 months, but you should rotate them at least annually. Set a calendar reminder one month before expiry. A lapsed secret takes down your entire authentication flow instantly and silently, there's no graceful degradation.
Monitor with Azure Monitor from day one. Connect your B2C diagnostic logs to Azure Monitor before you go live. Waiting until something breaks to set up observability means you'll be troubleshooting blind when it matters most. Send logs to a Log Analytics workspace and set up an alert for any spike in SignInLogs where ResultType != 0.
Use custom domains in production. Azure AD B2C supports custom domains so your login page appears at login.yourapp.com rather than yourtenant.b2clogin.com. Beyond the brand experience, this also insulates you from any future Microsoft changes to the default B2C domain. Configure it under Azure AD B2C → Custom domains using Azure Front Door.
Document your policy and user flow inventory. Keep a simple internal doc that lists every user flow and custom policy in your tenant, what application(s) use it, what changes were made and when, and who owns it. This sounds basic but it's the single thing that saves the most time when onboarding new engineers or diagnosing a mystery configuration.
- Enable CAPTCHA on your sign-up user flows to block bot registrations and reduce credential stuffing risk, it's built directly into B2C and takes five minutes to turn on
- Set up Conditional Access policies within your B2C tenant to require MFA for high-risk sign-ins, these are under Azure AD B2C → Security → Conditional Access
- Use MSAL's built-in token caching instead of rolling your own, it handles silent token refresh correctly and avoids the most common "user gets logged out randomly" complaints
- Regularly review the Identity Protection dashboard under Azure AD B2C → Security to catch password spray and brute force attempts before they affect real users
Frequently Asked Questions
What is Azure AD B2C and how is it different from regular Azure Active Directory?
Azure AD B2C is a customer identity access management service, it's built for letting your end users (consumers, customers, anyone outside your organization) sign up and sign in to your applications. Regular Azure Active Directory (now called Microsoft Entra ID) is designed for your employees and internal users. The key difference: B2C has no restrictions on who can create an account, supports social identity providers like Google and Facebook natively, and gives you full control over the sign-in UI/UX with white-label branding. It runs at massive scale, billions of authentications per day, and handles threats like brute force attacks automatically. Think of Entra ID as your IT directory and B2C as your customer login system.
Which MSAL library should I use with Azure AD B2C for my app?
Microsoft builds and supports MSAL libraries for every major platform, and B2C works with all of them. Use MSAL.js for React, Angular, Vue, or vanilla JavaScript single-page apps. Use MSAL.NET for ASP.NET Core and .NET MAUI apps. Use MSAL iOS (also called MSAL for Apple platforms) for Swift and Objective-C iOS and macOS apps. MSAL Java covers Android and Java server apps, and MSAL Python covers Python applications. The key thing all of them share when targeting B2C: you must configure the authority to point to your B2C tenant's user flow endpoint, not the standard Entra ID authority, and you must include the user flow name in the authority URL. All official MSAL libraries handle the B2C-specific token format and claim structure correctly out of the box.
Why is my Azure AD B2C access token missing the claims I need?
This is the most common Azure AD B2C head-scratcher, and the answer is almost always the same: you haven't explicitly checked those claims under Return claim in your user flow configuration. B2C doesn't return every attribute it stores, it only returns the claims you specifically opt into. Go to Azure AD B2C → User flows → [Your Flow] → Application claims and check every attribute you want in the token. Save the flow, then test it with Run user flow and paste the resulting token into jwt.ms to verify. If the claim still doesn't appear after that, check whether the attribute is being collected during sign-up, a claim can't be returned if it was never written to the user's profile.
Can I still use Azure AD B2C if it's no longer available to new customers?
As of May 1, 2025, Azure AD B2C is no longer available to purchase for new customers. If you already have an existing B2C tenant, Microsoft continues to support it, your existing service isn't being switched off. For new projects, Microsoft's recommended path is Microsoft Entra External ID, which offers the same customer-facing identity capabilities with a more modern architecture and tighter integration with the broader Entra platform. If you're mid-project on a B2C implementation and wondering whether to continue, check Microsoft's official FAQ on the transition timeline, existing customers retain full access and support, so finishing a B2C implementation that's already underway is generally fine.
How do I let users sign in with Google or Facebook through Azure AD B2C?
You need to do three things in the right order. First, register an OAuth app in the external provider's developer console (Google Cloud Console for Google, Meta for Developers for Facebook) and get a Client ID and Client secret. When registering, set the callback URL to https://[yourtenant].b2clogin.com/[yourtenant].onmicrosoft.com/oauth2/authresp. Second, add the social identity provider in Azure AD B2C → Identity providers using those credentials. Third, and this is the step people forget, go to your user flow, edit it, and add the new identity provider to the flow under Identity providers. It won't show up for users until you explicitly add it to each relevant flow. Then test with Run user flow before deploying.
What's the difference between user flows and custom policies in Azure AD B2C?
User flows are the no-code, pre-built option, you configure them through the Azure portal UI by making selections and clicking buttons. They cover the most common authentication scenarios: sign-up/sign-in, password reset, profile editing. For the vast majority of apps, user flows are all you need and they're significantly easier to maintain. Custom policies (built on the Identity Experience Framework) are XML-based configuration files that give you complete control over every step of the authentication journey. You'd use custom policies when you need to call an external REST API during sign-in, integrate a SAML enterprise IdP, chain multiple user journeys together, or implement logic that user flows simply don't support. Custom policies are powerful but they're also the source of most advanced B2C troubleshooting sessions, start with user flows and only move to custom policies when you hit a specific limitation.