Sp-dev-docs: AadHttpClient or MSGraphClient does not work with multiple live accounts

[edijsf]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When multiple accounts found user interaction for choosing correct account should be provided

Observed Behavior

When multiple live account logged in or when current service account does not match any live account you get error.

Steps to Reproduce

When you are logged in SharePoint where SFPX web part exists that connects to Azure services wither using AadHttpClient or MSGraphClient client and check it works fine. Then open in new browser tab Azure portal do sign-out and log in with different account and switch to SharePoint tab and refresh.
Or when multiple live accounts found you will get similar issue.

Following errors are not processed.
Error in case of multiple live accounts found:
AADSTS70002: Error validating credentials. AADSTS16000: Request is ambiguous: multiple user identities are available for the current request
Error in case of account mismatch
AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint

Proposed solution

Solution @microsoft/sp-http

// AdalAuthContext.js
67: AdalAuthContext.prototype._fetchAccessTokenSilent = function (resourceEndpoint) {`
.
.
73: if (_this._authContext._getItem(_this._authContext.CONSTANTS.STORAGE.ERROR) === 'interaction_required') {

Only one error is processed "interaction_required", but should process also when above mentioned errors are found.

[araver]

They can also avoid the login prompt by adding the "extraQueryParamter" to config of the "AuthenticationContext" constructor that hints at the current user.

var authContext = new AuthenticationContext({
    clientId: clientId,
    tenant: aadTenantId,
    redirectUri: window.location.origin + '/_forms/spfxsinglesignon.aspx',
    extraQueryParameter: '[email protected]'
});

[pkmelee337]

Just ran into the same problem. Logged in with 2 microsoft account.

[araver]

This is how i did it using ADAL

async getToken(headers: Headers) {
        var tp = await this.context.aadTokenProviderFactory.getTokenProvider();
        var config = tp["_defaultConfiguration"];
        var user = this.context.pageContext.user.loginName;
        var aadInstanceUrl = config.aadInstanceUrl[length - 1] === "/" ? config.aadInstanceUrl : config.aadInstanceUrl + "/";
        var ctx = new AuthenticationContext({
            tenant: config.aadTenantId,
            clientId: config.servicePrincipalId,
            instance: aadInstanceUrl,
            redirectUri: config.redirectUri,
            extraQueryParameter: "login_hint=" + encodeURIComponent(user),
            loadFrameTimeout: 60000
        });

        var cu = ctx.getCachedUser();
        console.log("USER", cu, user, ctx);
        if (cu && cu.userName.toLowerCase() !== user.toLowerCase()) {
            ctx.clearCache();
        }
        var token = await this.acquireToken(ctx, this.resource);
        if(headers.has("Authorization")){
            headers.set("Authorization", "Bearer " + token)
        }else{
            headers.append("Authorization", "Bearer " + token);
        }
    }

    private acquireToken(ctx: AuthenticationContext, resource: string){
        return new Promise<string>((resolve, reject) => {
            ctx.acquireToken(resource, (message, token) =>{
                if(!token){
                    reject(message)
                }else{
                    resolve(token);
                }
            });

        });
    }

[VesaJuvonen]

As this is not really an end-user scenario as they typically have one account, how often you'd really run into this issue unless you are a consultant with multiple accounts... and in this case incognito and profiles would help. Are we missing something on this? Sure - it could be a better implementation, but is this really a common scenario?

[araver]

My only concern is for a client that might have a shared workstation and the users don't clear the browser cache.

[pkmelee337]

Well, we did have some end users running in this problem allready. Most of them having some kind of admin and a normal account. After some time they did understand what caused it and that a normal user won't bump into this problem, but it's quite hard to explain.

[kasgit]

It works for all browsers except IE 11 for us. We are using SPFx 1.6. Below is the error message we are getting. @VesaJuvonen, Problem is we have multiple O365 tenants in our company and users who still use IE11 will face this issue. It works in IE11 inprivate. But we can't ask all the users to use InPrivate mode.

I have noticed that it is not sending login_hint with authorize request.

AADSTS70002: Error validating credentials. AADSTS16000: Request is ambiguous: multiple user identities are available for the current request.

[lucmoco]

We experienced the same problem with a regular user: in addition to our company tenant, he had added credentials for a school where he's attending some courses. And he experienced an error while using our web part, which is using the aadHttpClient to connect to a back-end API.

[michel-weber]

@VesaJuvonen It seems to be a problem for some of our end-users ... although it seems to be an edge case and will not affect a majority of our users it still is a blocking issue for some of them. As far as I know we do not have a work-around at the moment (I work in the same team as @lucmoco).

[2toLeadMike]

Any update on this? I believe we are seeing a similar issue on our end. Is there any way to force login_hint within SPFx without resorting to ADAL?

[baywet]

@VesaJuvonen end users are having the problem as well. Imagine they used their private account (either Hotmail or Gmail) to log on a consumer service/B2C partner tenant (like I don't know the school board of their district typically) and they are logged in with their corporate account on the corp tenant at the same time.

[baywet]

to follow up the workarounds @araver is suggesting might work for aadhttpclient, but not for graph client as the factory does not expose the getprovider method (at least not in 1.6.0/1.7.1).
Setup:

• invite a ms account to a tenant (any tenant) as external user
  The exact repo case is:
• start with an in private browser
• log on to OneDrive.live.com with the MSA
• go to your SharePoint site with your extension or webpart that calls AAD secured APIs or the Graph, log in with your corp account
• you get the error
  Also linking that for reference https://github.com/AzureAD/azure-activedirectory-library-for-js/issues/580

[VesaJuvonen]

Thanks everyone for your input on this. We are aware of this and looking into shipping fix for this as part of the 1.8 release coming in a matter of weeks rather than months... task is currently prioritized as 'must' thing to fix for the release.

[MaheshakaMudli]

@VesaJuvonen : Our clients are facing this issue on a daily basis and we need solution for it as soon as possible. Is there any specific time by when we can expect 1.8 release which will get shipped with this issue as resolved.

[evobis]

@VesaJuvonen : this is also a big issue for our client and as mentioned in an earlier post, it is impossible to explain this issue to a customer.
What is the eta on the above mention 1.8 release ? :)

[michel-weber]

According to:

SharePoint Dev Weekly - Episode 28 - 26th of February 2019
https://youtu.be/oYKBFF7KiKM

ETA 1.8 Release: Soon

[evobis]

Thanks @michel-weber :)

[akhilohri]

According to SharePoint Developer Monthly Community Call - March 2019 (https://www.youtube.com/watch?v=YntZdZy0NvM), SPFx 1.8 will be shipped SOON (This Month).

Going forward, for new tenants, root site will be a communication site!

[kachihro]

SPFX v1.8... Soon - as in, NOW ! 8 hrs ago...

[akhilohri]

And it's Finally here!!

Announcing the General Availability of SharePoint Framework 1.8

Published March 14, 2019

@2toLeadMike @pkmelee337 @araver @kannansgit @lucmoco @michel-weber @MaheshakaMudli @evobis @baywet

[evobis]

I've just updated my spfx solution to 1.8 by following the guide on https://github.com/SharePoint/sp-dev-docs/wiki/SharePoint-Framework-v1.8-release-notes. I still get the "multiple accounts" error.

My code:

let graphClient: MSGraphClient = await this.context.msGraphClientFactory.getClient();
        let url = "/users?$top=100&$orderBy=displayName&$select=displayName,jobTitle,mail,mobilePhone,department,userPrincipalName,accountEnabled";
        let result = await graphClient.api(url).get();

Did anyone get it to work after the new version ?

[keschte]

I can confirm the issue has not been fixed with 1.8.

AADSTS16000: Either multiple user identities are available for the current request or selected account is not supported for the scenario.
Trace ID: b268a425-fcff-492e-b8f4-a9a895b72900
Correlation ID: fb6d467b-9607-4aae-a048-8016aeb212f9

/cc: @lucmoco @michel-weber

[evobis]

@VesaJuvonen - was this solved in the 1.8 release and are we just missing something or was it left out ? :)

[lucmoco]

As I understand the authentication process, the fix for this problem must be implemented server-side in SharePoint and not client-side in the SPFx framework. Hopefully the fix will be deployed in tenants soon. Otherwise we'll have a big problem since we have more and more web parts using the aadHttpClient to connect to back-end APIs, and more and more users complaining that our web parts don't work because of this bug.

[heinrich-ulbricht]

We ran into this problem today.
Our scenario is: one tenant for business use, one tenant for non-business use, OneDrive-synched document library from each tenant. Boom. SPFx webparts consuming Microsoft Graph stop working.
(We worked around this issue by un-linking one of the accounts in OneDrive and removing the account from Windows. Just clearing browser cache/deleting local storages did not work. Private tab always worked though.)
@VesaJuvonen Could you provide a status update on this issue please? We could either wait or change our solutions. Which we won't do if a fix is due soon.

Some technical context:

• Chrome
• SPFx < 1.8
• Windows 10

[xgracs]

We have upgraded to 1.8 and the issue still exists. For us it is only happening with external user, or users signing in with a Live account (i.e. gmail, hotmail, etc). The error is:

Error: AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.
_Trace ID: 2ae830d7-2265-4467-9a6d-de2573282500
Correlation ID: 16213db4-408c-40db-b6d3-5d16fe3f854c
Timestamp: 2019-03-29 15:09:23Z
at Array. (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-webpart-workbench-assembly_en-us_e89df8408f4d327c94e46017237276f5.js:1064:34992)
at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/1.sp-http-adal_c2097657830cc37ce4b2.js:3:7561)
at AuthenticationContext.handleWindowCallback (https://secure.aadcdn.microsoftonline-p.com/lib/1.0.16/js/adal.min.js:2:24607)
at parseTokenFromUrl (https://[site]/_forms/spfxsinglesignon.aspx:20:17)
at onload__

[LauraKokkarinen]

Hi,

I'm also getting this error message when I'm logged in with a guest user account (an AAD user from another tenant). The web part is trying to call Microsoft Graph. Works perfectly for the organization's internal users. The web part was originally implemented with SPFx 1.6.0 version in early Novemeber 2018, and the customer reported of this issue on the 21st of March 2019. I updated the web part to SPFx 1.8.0 version but the problem persists.

Could you take a look at this, let us know if there is a schedule for the fix, and if there is a workaround we could use in the meanwhile? Thank you!

Laura

snip-web-part_901938be19c3b11dc5c2243f82b2eb99.js:formatted:93 Uncaught (in promise) Error: AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.
Trace ID: 2d157d4a-a742-465c-8e25-36f8541e4100
Correlation ID: 5315f60a-2f9d-4551-b016-dd72f4dd0fd0
Timestamp: 2019-04-01 09:58:56Z
at Array. (sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1189)
at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/1.sp-http-adal_c2097657830cc37ce4b2.js:3:7561)
at AuthenticationContext.handleWindowCallback (adal.min.js:2)
at parseTokenFromUrl (spfxsinglesignon.aspx:20)
at onload (https://snip.sharepoint.com/_forms/spfxsinglesignon.aspx#error=login_required&error_description=AADSTS50058%3a+A+silent+sign-in+request+was+sent+but+none+of+the+currently+signed+in+user(s)+match+the+requested+login+hint.%0d%0aTrace+ID%3a+2d157d4a-a742-465c-8e25-36f8541e4100%0d%0aCorrelation+ID%3a+5315f60a-2f9d-4551-b016-dd72f4dd0fd0%0d%0aTimestamp%3a+2019-04-01+09%3a58%3a56Z&state=e78cc4a0-0fd1-436c-8f18-36ae2dd9593d%7c5e030ed5-0442-4530-9abc-a3b61c6e3227:31:38)

[xgracs]

Any suggestions on workarounds? We have several pages unusable to groups of users that we have our sites shared with.

[advdberg]

As @LauraKokkarinen says, we also see in our solutions that this issue is now not longer only for multiple live accounts, but also with one live/outlook.com/other O365 tenant -account in an in-private browser. When the SPFx web part is only using the SP client it works fine, as soon as the Graph client is used, the error is shown for all external/guest users. For internal users it works fine. @VesaJuvonen any news on this?

While @LauraKokkarinen already did the update to 1.8 and still hase the issue, we haven't updated it for now...

Browser: Chrome
SPFx: 1.7.1
User: [email protected] or from other O365 tenant
Usertype: Guest
Site: Modern Teamsite connected to private O365 Group

[advdberg]

Also see #3722 MSGraphClient does not work for Guest user
Seems to be the same issue

[andrewconnell]

@baywet Didn't you confirm that a fix was identified and rolling out to address multiple accounts logged in and hitting this issue in SPO? I thought you mentioned that to me a few weeks ago when we were together in Redmond...

[baywet]

@andrewconnell I'm not sure what the NDA is on that or even where are things at right now.

But basically I confirmed that the fix I was asked to test fixed the following scenario:
User is logged with two Office 365 accounts at the same time on AAD, accesses a webpart leveraging the MSGraphHttpClient and gets the following error: AADSTS70002: Error validating credentials. AADSTS16000: Request is ambiguous: multiple user identities are available for the current request.

Now as of today, I'm not sure where is this fix in terms of deployment, it'd be good if engineering could jump in and clarify the status.

I do think there are more cases than the one I was asked to test and/or if this fix was indeed deployed, it introduced a new issue: If I'm logged with a live account and accessing a webpart leveraging aad/msgraph httpclient, because the hint doesn't match (not sure what the implementation is), AAD replies that the user is not logged in when requesting the token, which maps to this error: AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.

The story "scenario A was fixed and deployed but either didn't fix scenario B or worsen it" would explain the surge in comments about scenario B in the last days.
I hope that clarifies the situation a little bit, @akhilohri : can you take this discussion internally, do we have availability for our QA team to retest the different scenarios I just mentionned on the impacted projects? (at least one of those)

[xgracs]

We still have this issue. We've implemented a temporary workaround for external users only using iframes to try and get the AAD app to authenticate using the standard sphttpclient. But it feels more like a hack then a workaround. It also doesn't fix the issues with MSGraphClient though, those still exist. Any updates on when the AadHttpClient will be usable again for external users?

[keschte]

@xgracs Can you share (code) how your temporary workaround works?
BTW: Why not implement it using adal.js directly, and not use aadHttpClient at all?

[andrewconnell]

Seems related to #3722 ... I'll flag MSFT engineering for investigation...

[xgracs]

@keschte - I'll share what I have as soon as I get it working again. Came in today and it no longer works. I haven't used adal simply because I was hoping there would be a quick turnaround fix. Also, the AadHttpClient was so easy to use. I was super excited for 1.6 when it was available. It's looking like a quick fix won't be the case though, so I'm looking into adal today as well.

[valpvt]

It seems that Microsoft magically fixed our Office 365 tenant today regarding the issue with guest accounts. How about yours?

[andrewconnell]

See: https://github.com/SharePoint/sp-dev-docs/issues/3722#issuecomment-481342576

[evobis]

@andrewconnell Why did this bug get closed ? I still have the same issue with multiple accounts while using MSGraphClient. What was the soluton ?

[michel-weber]

@andrewconnell This is not a duplicate. Please reopen this is not fixed (separate problems).

[valpvt]

@andrewconnell Why did this bug get closed ? I still have the same issue with multiple accounts while using MSGraphClient. What was the soluton ?

@andrewconnell Indeed this issue should not be closed. Only the introduced bug with guest accounts has been resolved, not the one with multiple accounts which lasts for months.

[andrewconnell]

My bad... saw the comment that it was fixed...

[xgracs]

We have several sets of users validating this, but so far it does look like the AadHttpClient is functioning correct, like it was previously. Not the MSGraphClient though. Does anyone know what happened that it suddenly started working again? It would be nice to tell Management that xyz release was pushed out and that's what made the fix available. I'm guessing there isn't any official release like that for this though?

[andrewconnell]

@xgracs see my comment above: https://github.com/SharePoint/sp-dev-docs/issues/2629#issuecomment-482130639

That links to where MSFT's engineering stated a regression was fixed. You won't get more detail than that as MSFT doesn't explicitly state this detail.

[xgracs]

Thanks @andrewconnell it at least gives me something to reference.

[VesaJuvonen]

This fix should be now 100% rolled out and the issue should be fully fixed. If that's not the case, please do let us know.

[evobis]

@VesaJuvonen awesome. :)
I just tested it on the customers tenant while logged in to several other O365 accounts and it seems to be working now. Thank you. 👍

[VesaJuvonen]

Thanks, @evobis for confirming the status. It was, unfortunately, quite a long journey, but should be now fine. If anyone still sees this issue, please open up a NEW issue so that we can track that and reference this one.

[jennings1716]

I am getting the same issue, when multiple users are logged in. I am using adalFetch to fetch the user's profile. I got this error "AADSTS16000: Either multiple user identities". If this issue is resolved, please do post the solution.

[andrewconnell]

@jennings1716 this issue is closed... if you are having the issue, please submit a new issue with relevant context to investigate... thanks.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues