[Bug] Cannot use emailAddress with PublicClientApplication using ROPC flow

[pizerg]

Library version used

1.23.1

Java version

24.0.1

Scenario

PublicClient (AcquireTokenInteractive, AcquireTokenByUsernamePassword)

Is this a new or an existing app?

This is a new app or experiment

Issue description and reproduction steps

When configuring our e2e test we're using a PublicClientApplication with ROPC flow (target platform being MS Entra External ID), when trying to authenticate via email + password using UserNamePasswordParameters the call to acquireToken fails with the following exception:

java.util.concurrent.ExecutionException: com.microsoft.aad.msal4j.MsalServiceException: AADSTS90002: Tenant 'mydomain.test' not found. Check to make sure you have the correct tenant ID and are signing into the correct cloud. Check with your subscription administrator, this may happen if there are no active subscriptions for the tenant.

It seems to be trying to get the tenant from the email after the @, so if using customer@mydomain.test it tries to use mydomain.test as tenant (tenant is correctly specified in the AUTHORITY field), if I try to specify the tenant manually using UserNamePasswordParameters.builder(....).tenant("TENANT_HERE") it seems to be simply ignored.

The customer@mydomain.test is a Local Account created manually and Sign-in Identifiers is enabled and configured for both Email and UPN.

If instead using the email I use the UPN in the form of [ID]@[TENANT].onmicrosoft.com without changing anything else, the authentication succeeds without a problem

Relevant code snippets

PublicClientApplication pca = PublicClientApplication.builder(APP_ID)
                    .authority(AUTHORITY)
                    .build();

UserNamePasswordParameters parameters =
                UserNamePasswordParameters.builder(
                                SCOPES,
                                username,
                                password.toCharArray())
                        .build();

pca.acquireToken(parameters).get();

Expected behavior

Authentication comples without issue when using either emailAdress or UPN.

Identity provider

Microsoft Entra External ID

Regression

No response

Solution and workarounds

No response

[Avery-Dunn]

Hello @pizerg : I don't believe the library parses the username in anyway, and I just tested the username/password flow myself and for me at least it seems like setting the tenant field of the UserNamePasswordParameters will override what is set at the application level and show up in that AADSTS90002 error

Just to confirm, when you say UserNamePasswordParameters.builder(....).tenant("TENANT_HERE") and [ID]@[TENANT].onmicrosoft.com, the real tenant value you're using is neither the "mydomain.test" tenant name or that tenant's ID, right? It's some other tenant name or tenant ID that you know is different?

If so, my best guess is that something on the Azure/token service side is looking at the username to determine the tenant, and perhaps that's caused by some sort of configuration on the Azure side. I'm not sure the best place to start looking for answers about that, and this whole username/password flow is deprecated both here and in Azure so even if there is an issue I don't know if it would be fixed.

[pizerg]

Hello @Avery-Dunn,

The values I posted were examples to avoid sharing the real domains publicly but the authority I'm using has the following shape:

https://[TENANT_NAME].ciamlogin.com/[TENANT_ID]

As for the username the one that works has the shape:

[OBJECT_ID]@[TENANT_NAME].onmicrosoft.com

While the one that does not work just looks like an email address.

We are not using this flow in production but it still seems to be the recommended way to perform automated tests that need to authenticate agains MS Entra External ID without having to automate the login flow on a third party (MS Entra External ID login pages).

I thought it might be a library issue since pca.authenticate method calls UserIdentifier.fromUpn(String upn) but I guess that should work for email addresses as well.

I can try to dig deeper in the config to see if I missed something or test the same flow with other msal libs to check if they allow this specific use case, in any case this is not critical it's just a bit inconvenient that we cannot directly use email address for the tests.