Microsoft-authentication-library-for-js: Duplicate domain_hint caused by MSAL not respecting AuthenticationParameters

[AndrewCraswell]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Library version

Library version: 1.2.0-beta.4

Current behavior

Our site has different enterprise customers using AAD login. In order to display the login page with their company branding, we pass a domain_hint=[domain].com parameter as part of the extraQueryParameters in AuthenticationParameters. It seems there are scenarios where msal will automatically add a domain_hint parameter of values organization or consumer depending on the client info. This is causing sign in to fail for some users, and a "Duplicate domain_hint" error to be displayed.

Expected behavior

If a domain_hint is provided, this should be respected by msal.

Source:
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-core/src/ServerRequestParameters.ts#L245

[AndrewCraswell]

@sameerag Thanks again for syncing with us on this issue. :)

[razi-rais]

I'm experiencing the exact same issue MSAL.js including domain_hint twice

Is there a workaround or resolution available? It is blocking the work I am currently doing using MSAL.js and Azure B2C.

[sameerag]

Thanks @AndrewCraswell. I will follow up on this early next week and update the PR here.

[PoyaManouchehri]

We are also affected by this and it's a high priority issue. The request for id_token seems to respect the domain_hint correctly, however during the token request domain_hint is sent twice, one being the domain I supplied and the second being organization

Would be keen to hear if a fix is scheduled soon and if there is a workaround in the meant time. Thanks!

[sameerag]

@AndrewCraswell and @PoyaManouchehri; we heard from the service and the recommendation here is to support domain_hint (whatever the user sets it to) in interactive calls and ignore it for silent calls (it isn't supported at all). Though the fix is simple, this may need extensive testing as we are changing behavior that has been in production for some time.

Please expect this to be merged in a week if there are no bugs found around it. :-).

cc @tnorling

[alex-mason-by]

@sameerag I am assuming that "isn't supported at all" doesn't mean it's broken in this case of using domain hints but intended that silent calls will get tokens based on the context of the account that originally was authenticated using the domain hint? In other words, the domain hint isn't needed for silent calls because the account has been established.

[sameerag]

Yes. In addition to this assumption, we are also preferring to ignore domain_hint for silent calls in the case of user setting a wrong domain_hint that could prompt silent calls to fail (requiring interaction if the account is looked up in the wrong domain).

[alex-mason-by]

I am pretty confused on this because I am issuing particular custom token claims based on the B2C identity provider resolved by the domain_hint and also using the domain_hint in a home realm discovery (HRD) scenario. I am not sure how it would work without the domain_hint for access tokens resolved silently. This all works fine on the initial return (id token and access token both) but now am wondering how it could work if no domain_hint is passed.

[sameerag]

UPDATE:

We have decided we will no longer populate domain_hint from the library - organizations and consumers. The new policy on domain_hint for msal js will be as follows:

• We will be passing customer's choice of domain_hint to the server for interactive calls
• We will ignore any domain_hint passed for silent calls (as a wrong domain_hint can cause an error in authentication the user cannot address in silent calls)

The changes are now in a PR #1299 which will soon be merged.
cc @AndrewCraswell and @PoyaManouchehri

[PoyaManouchehri]

@sameerag any updates on this? I can see the PR has been inactive for a while.

[ajayrknair430]

Thanks @sameerag for looking into this. Any updates on when this would be merged?

[tnorling]

A fix for this, as described by @sameerag above, was included in [email protected]. Please let us know if this issue is resolved.

[alex-mason-by]

I can confirm that this fix was a contributor in resolving our MSAL.js/B2C silent token renewal issue. We also had adjust our custom policy to persist some custom claims around our home realm discovery logic.

[sameerag]

Thanks @alex-mason-jdas. Closing the ticket.