Identity Management

AADB2C90018 Solved: Ultimate 2025 Tenant Fix Guide

Struggling with the AADB2C90018 error in Azure AD B2C? Our 2025 guide provides the ultimate fix, from user flows to custom policy debugging. Solve it for good!

Alex Volkov

Microsoft MVP in Identity & Access Management with over a decade of cloud security experience.

September 8, 20256 min read18 views

If you're a developer working with Azure AD B2C, you've probably seen your fair share of cryptic error codes. But few are as initially confusing—and ultimately as straightforward—as AADB2C90018. You've configured everything, you're testing your sign-in flow, and suddenly your app is redirected to a URL containing this code. What gives?

Don't worry. This isn't a critical tenant failure or a sign that your policies have completely imploded. In fact, it's usually a sign that things are working exactly as they should be. This guide will demystify the AADB2C90018 error, show you why it happens, and give you the ultimate fix-it plan for 2025.

What is the AADB2C90018 Error, Really?

Let's get this out of the way first: AADB2C90018 is not a bug; it's a signal. The official description is "The user has forgotten their password."

Unlike other errors that signify a misconfiguration, AADB2C90018 is part of B2C's designed control flow. When a user in a sign-in journey clicks the "Forgot your password?" link, B2C intentionally halts the current process and redirects back to your application. It appends error=access_denied and error_description=AADB2C90018: The user has forgotten their password. to the URL.

Think of it as B2C tapping your application on the shoulder and saying, "Hey, this user needs to reset their password. You should probably initiate the password reset policy flow for them now." Your application is then expected to catch this signal and start the correct user journey.

Common Triggers & Misconfigurations

So if it's an expected signal, why does it feel like an error? It usually pops up unexpectedly for one of three reasons:

Legitimate User Action: A user genuinely clicked the "Forgot password?" link. Your app just isn't handling the redirect gracefully. This is the most common and intended scenario.
Custom Policy Misconfiguration: This is the sneakiest cause. An incorrect setting in your XML files might be prematurely or incorrectly triggering the password reset flow, even when the user didn't ask for it.
Incorrect Application Request: Your web or mobile app might be accidentally sending users to the wrong policy. For example, it might be calling the password reset policy instead of the sign-up/sign-in policy.

The Ultimate Tenant Fix Guide

Let's walk through how to diagnose and fix the issue, from the simplest cause to the most complex.

Step 1: Verify Your Standard User Flows

If you're using Azure's built-in User Flows (not custom policies), the fix is often straightforward. The AADB2C90018 code is the standard behavior. The "fix" here isn't in Azure, but in your application's code. Your app needs to be programmed to detect the AADB2C90018 description in the URL and then trigger a new authentication request, this time pointing to your Password Reset user flow.

Most modern authentication libraries (like MSAL) have patterns for handling these types of interaction-required responses. Ensure your callback/redirect handler checks for this specific error description.

Step 2: Deep Dive into Custom Policies

This is where things get interesting for those of us living in the world of XML. If users are being forced into a password reset without clicking anything, you likely have a logic error in your Relying Party (RP) file or one of its inherited files.

Check Your Default User Journey:

The most common culprit is an incorrect DefaultUserJourney in your sign-in Relying Party file. It might be accidentally pointing to your password reset journey instead of your sign-in journey.

Open your SignUpOrSignin.xml (or equivalent) file and find the section. Look for this:

<!-- MISTAKE: The default journey is incorrectly set to the password reset flow -->
<DefaultUserJourney ReferenceId="PasswordReset" />

If you see this, you've found your problem. B2C is doing exactly what you told it to do: run the password reset journey by default. Change it to your primary sign-up/sign-in journey:

<!-- CORRECT: The default journey should be the main sign-in/sign-up flow -->
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />

Inspect Orchestration Step Preconditions:

Another potential issue is a faulty Precondition in an OrchestrationStep that incorrectly routes the user. For example, a step might be checking for a claim that doesn't exist and, as a fallback, branching to the password reset technical profile. Scrutinize the user journey referenced in your RP file and trace its steps logically.

Step 3: Audit Your Application's Requests

Sometimes, Azure is configured perfectly, but your application is making the wrong request. You can verify this easily using your browser's developer tools.

Open your browser and press F12 to open Developer Tools.
Go to the Network tab.
Check the "Preserve log" box.
Trigger your application's sign-in flow.
Look for the first request to your B2C login endpoint (e.g., https://yourtenant.b2clogin.com/...).
Inspect the URL parameters. Look for the p= parameter.

This parameter specifies the policy to run. If you see p=B2C_1A_PASSWORDRESET (or your custom policy's name for password reset) when you intended to sign in, then the issue is in your application's code that constructs this authentication URL. Dig into your MSAL configuration or wherever you define the policy names to call.

Step 4: Implement Graceful Handling

As mentioned in Step 1, the best practice is to handle this signal gracefully. When your application receives the AADB2C90018 error, it should not crash or show a cryptic message to the user.

Instead, your redirect logic should:

Detect the error_description containing "AADB2C90018".
Automatically initiate a new authentication request against your Password Reset policy.
This creates a seamless experience where the user clicks "Forgot Password," is briefly redirected, and then immediately sees the password reset screen.

A Pro-Tip for Easier Debugging

If you're wrestling with custom policies, your best friend is Application Insights. Integrating Application Insights with Azure AD B2C provides incredibly detailed, step-by-step logs of every user journey execution.

When you encounter an unexpected flow, you can open Application Insights and see the exact trace of the journey. It will show you which OrchestrationStep was executed, what the claim values were, and precisely where the journey was diverted to the password reset flow. This eliminates guesswork and takes you directly to the source of the problem in your XML files.

Wrapping It Up

The AADB2C90018 error code is more of a message than a malfunction. It's a fundamental part of how B2C communicates user intent back to your application.

By remembering the three potential causes—legitimate user action, policy logic, or application request—you can quickly diagnose the situation. Start by checking your application's request URL, then dive into your custom policy logic if needed. And most importantly, build your application to handle this signal gracefully, creating a smooth and intuitive experience for your users.

Happy coding!