Debug AADB2C90018: 5 Reasons Your Client ID Fails (2025)

AADB2C90018: The client id '[some-guid]' specified in the request is not registered in tenant '[your-tenant].onmicrosoft.com'.

// Example from appsettings.json
{
  "AzureAdB2C": {
    "Instance": "https://yourtenant.b2clogin.com",
    "ClientId": "PASTE_THE_FRESHLY_COPIED_ID_HERE", // <-- Right here!
    "Domain": "yourtenant.onmicrosoft.com",
    "SignUpSignInPolicyId": "B2C_1_signup_signin"
  }
}

The correct B2C authority URL format is:

https://<your-b2c-tenant-name>.b2clogin.com/<your-b2c-tenant-name>.onmicrosoft.com/<your-user-flow-or-policy-name>

Let's break that down:

• <your-b2c-tenant-name>: This is the unique name of your B2C tenant, not your standard Azure tenant. You can find it in the Azure portal when you switch to the B2C directory. It's often something like contosob2c.
• <your-user-flow-or-policy-name>: This is the name of the specific user flow you want to trigger, like B2C_1_signup_signin.

Here's how your appsettings.json should look with the correct values:

// Correct B2C Configuration
{
  "AzureAdB2C": {
    // Correct: uses b2clogin.com
    "Instance": "https://contosob2c.b2clogin.com",
    "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    // Correct: uses the B2C tenant's full domain
    "Domain": "contosob2c.onmicrosoft.com", 
    "SignUpSignInPolicyId": "B2C_1_signup_signin"
  }
}

Double-check that you're using b2clogin.com and that the domain/tenant name is your B2C tenant's name, not your primary work tenant.

Reason 3: The App Isn't Linked to Your User Flow

This is a B2C-specific step that's easy to miss. Just because an application is registered in your B2C tenant doesn't mean it's automatically allowed to use every user flow. For security, you must explicitly grant permission.

The Problem

The app registration exists and the client ID is correct, but the specific user flow (e.g., sign-up, sign-in, password reset) that you're calling hasn't been configured to allow this application to use it.

The Fix

You need to associate your app registration with the user flow.

1. In the Azure Portal, go back to your Azure AD B2C service.
2. Under "Policies," click on User flows.
3. Click on the name of the user flow that is failing (e.g., B2C_1_signup_signin).
4. In the user flow's navigation menu on the left, under "Manage," click Applications.
5. You'll see a list of applications registered in your tenant. Find your application in the list and ensure its checkbox is ticked.
6. If it's not checked, check it and click Save.

This step tells B2C, "Yes, I trust this application with this client ID to use this specific authentication policy." If you're using Custom Policies, the equivalent is ensuring your <RelyingParty> element correctly references your application's client ID.

Reason 4: Using the Wrong Endpoint Version

The Microsoft identity platform has evolved, with v1.0 and v2.0 endpoints. Azure AD B2C is built exclusively for the modern v2.0 endpoint. Using code or a library configured for the v1.0 endpoint will cause issues.

The Problem

Your application is trying to communicate with B2C using a v1.0-style authority URL or authentication flow. B2C app registrations are only valid on the v2.0 endpoint, so the request is rejected before it even gets a chance to be properly evaluated.

The Fix

Ensure your entire setup is geared for v2.0. The easiest way to do this is to use the latest version of the Microsoft Authentication Library (MSAL) for your platform. MSAL is specifically designed for the v2.0 endpoint and has first-class support for B2C's unique authority URL structure.

The authority URL we discussed in Reason #2 is inherently a v2.0 endpoint URL. If you find any configuration pointing to login.microsoftonline.com/common/... or a tenant ID GUID in the URL path for a B2C flow, you're likely on the wrong track. Stick to the <tenant>.b2clogin.com/<tenant>.onmicrosoft.com/<policy> format.

Reason 5: The Dreaded Propagation Delay

You've checked everything. The ID is perfect. The tenant is correct. The user flow is linked. You're losing your mind. What could be left?

The Problem

Azure is a massive, globally distributed system. When you create or modify a resource—like an app registration or a policy link—it can take a few moments for that change to replicate across all the necessary backend services and geographic regions.

The Fix

Go get a coffee. Seriously. If you are 100% certain that your configuration is correct, wait for 2-5 minutes, and then try again. This propagation delay is much less common than it used to be, but it can still happen, especially if you create the app registration and try to use it within seconds.

Waiting a few minutes before diving into a frantic debugging session can save you a tremendous amount of stress.

Final Checklist Before You Go

Still stuck? Run through this quick checklist one last time:

• Client ID: Is the ID in my code identical to the one in the Azure Portal's App Registration? (Use a fresh copy-paste).
• Tenant: Is my authority URL using mytenant.b2clogin.com and not login.microsoftonline.com?
• User Flow Link: Is my application explicitly selected and saved in the "Applications" section of my User Flow settings?
• Policy Name: Does the authority URL in my code contain the correct and complete name of my user flow policy?
• Patience: Have I waited 5 minutes since my last configuration change?

The AADB2C90018 error is a gatekeeper, but it's one with a very specific set of keys. By methodically checking these five common issues, you'll find the right key and unlock the power of Azure AD B2C for your application. Happy coding!