AADB2C90011: Client Id keeps throwing an error when it is correct

Hello Andrew Saad,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

The AADB2C90011 error in this scenario is often not about the new User Flow or the new App Registration, but about the underlying Google Identity Provider's configuration within the tenant itself.

Your User Flow is designed to use Google as an Identity Provider (IdP). When you configured the original flow with the now-deleted app registration, the [OLD CLIENT ID] was saved in the federation metadata for the Google IdP. Even a brand-new User Flow will reference the same, single, tenant-wide Google Identity Provider. If that IdP configuration is corrupt or references a phantom ID, every User Flow that uses Google will fail in the same way.

The error message's format confirms this:

• The client id [NEW CLIENT ID] provided in the request : This is the client ID of your new App Registration (the Relying Party application that initiated the login).
• does not match client id [OLD CLIENT ID] registered in policy : This is the ID B2C is expecting, and it's the stale, phantom ID stuck in the policy's metadata.

The system is confusing the App Registration Client ID (what your app passes) with a Social Identity Provider Client ID (what the B2C policy expects to see), because of the corrupt, older entry.

I would recommend you to try below:

Delete and Re-create the Identity Provider: As outlined previously, the most reliable fix for this specific, deep-seated metadata corruption is to force the tenant to write a completely new configuration for the Google Identity Provider.

• Collect New Credentials: Ensure you have the correct Google Client ID and Client Secret from your Google Developer Console, corresponding to the application you want B2C to use for federation.
• Navigate to Identity Providers:
  • In the Azure portal, switch to your Azure AD B2C tenant.
  • Under Manage, select Identity Providers.
• Delete Google: Find and select the existing Google entry (it might be named something else if you used a custom name). Delete the entire Identity Provider configuration. This is the crucial step that purges the stuck [OLD CLIENT ID] metadata from the tenant's underlying policy files.
• Re-create Google: Click + Add. Select Google from the list. Provide a new Name (e.g., "Google-New"). Enter the new, correct Client ID and Client Secret. Save the new configuration.
• Test the New User Flow: Go back to your new user flow. Verify that the newly created Google IdP is selected under Identity Providers. Use Run user flow to test the new application ID against the newly configured Google provider.

This process forces a clean slate for the social login federation configuration, resolving the artifact that the new user flow and app registration inherited.

Please do refer below documents for better understanding:

https://learn.microsoft.com/en-us/azure/active-directory-b2c/error-codes

https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-google?pivots=b2c-user-flow

https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-user-flow

https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-overview

Hope this help!

Regards,

Monalisha

@Monalisha Jena Thank you for your prompt response.

I have tried the steps above and have waited some time before trying again. Actually the steps I took were:

1. delete all associated app registrations (I also deleted the api app registration)
2. delete the Google identity provider
3. delete the user flow
4. recreate the Web app registration
5. recreate the user flow
6. reconfigure the Google identity provider with a new client secret
7. associate the newly recreated app registration to the newly recreated user flow
8. wait 10 minutes

I still see the same behavior. This seems to be a persistent behavior