Sp-dev-docs: MSGraphClient does not work for Guest user

[Oaden]

Category

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

Expected or Desired Behavior

When using the MSGraphClient as guest user, it should return data

Observed Behavior

When using a guest account to call the /users endpoint, i get the following error

"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: b69ceeca-9d68-433a-9263-482773fa1a00
Correlation ID: af8b56b0-c4d9-491a-bf2d-11a89fdaafe9
Timestamp: 2019-04-02 12:29:49Z
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://devcrh.sharepoint.com/_forms/spfxsinglesignon.aspx:20:17)
at onload (https://devcrh.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+b69ceeca-9d68-433a-9263-482773fa1a00%0d%0aCorrelation+ID%3a+af8b56b0-c4d9-491a-bf2d-11a89fdaafe9%0d%0aTimestamp%3a+2019-04-02+12%3a29%3a49Z&state=8cb0bf92-8759-4dbc-bec2-ba8ef20cc545%7ca5279774-f79f-4ec5-a3ee-a33a6b0e80c7:31:38)"

Steps to Reproduce

using SPFx 1.8
When a guest (so with a address from another tenant) tries to use a spfx webpart that uses the MSGraphClient, the endpoint returns the error: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[GeorgiBoykov]

We are into the same issue...

The problem is in the login_hint parameter within the auth request of guest users. Azure AD seems to add some additional fragments to the guest user`s UPN. For example, if my guest account is [email protected], my Azure AD UPN will be xxx_yyy.zzz#ext#@company.onmicrosft.com. The SPFx webpart sends the formatted account as the login_hint but Azure AD does not recognize it as a valid login account and returns the above mentioned error!

I tried to replace the login_hint in the request while debugging with my original account (non-formatted) and it worked! So, there is nothing to do on the client side, because it is in the Microsoft SharePoint`s script. Here is the place where the login_hint parameter is sent as the formatted one (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:formatted):

Is there a solution for this issue, or it is a bug that will be fixed?

[justdevelopment]

We have the same issue as well. It this an issue in the SPFx SSO or with the underlying AAD things? Tagging in @VesaJuvonen & @patmill :)

[advdberg]

Also see the latest posts in #2629 AadHttpClient or MSGraphClient does not work with multiple live accounts
Seems to be discussing the same issue

[hornes9]

We are into the same issue...

The problem is in the login_hint parameter within the auth request of guest users. Azure AD seems to add some additional fragments to the guest user`s UPN. For example, if my guest account is [email protected], my Azure AD UPN will be xxx_yyy.zzz#ext#@company.onmicrosft.com. The SPFx webpart sends the formatted account as the login_hint but Azure AD does not recognize it as a valid login account and returns the above mentioned error!

I tried to replace the login_hint in the request while debugging with my original account (non-formatted) and it worked! So, there is nothing to do on the client side, because it is in the Microsoft SharePoint`s script. Here is the place where the login_hint parameter is sent as the formatted one (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:formatted):

Is there a solution for this issue, or it is a bug that will be fixed?

We have the same issue in our company. Something is messed up between Azure AD guest accounts and Spfx while authenticating. The reason is definitely in the formatted user principal name (UPN) of guest accounts. Please, this is critical for our application. @VesaJuvonen

[andrewconnell]

@advdberg said:

Also see the latest posts in #2629 AadHttpClient or MSGraphClient does not work with multiple live accounts Seems to be discussing the same issue

That's a different issue with multiple accounts logged into the same session at the same time and SPo getting confused on which one to use...

[andrewconnell]

I'm checking with the Graph team if this scenario is supported... something doesn't seem right for guest users to be able to get all users in the org... but checking...

@Oaden what scope did you grab have you granted SPO on MSGraph?

[justdevelopment]

I can imagine guest users not having access to certain graph endpoints, but surely they should then get the same access denied you get when your account has no access instead of just failing badly on a token request? We don't use the /users endpoint, but we do have quite a few scopes in our project so it could be any of the others.

[andrewconnell]

@justdevelopment said:

but surely they should then get the same access denied you get when your account has no access instead of just failing badly on a token request

Not necessarily... scopes are granted on a resource which is not the full URL of the endpoint, but rather the TLD (ie: graph.microsoft.com). At any rate, that (4** status code) is something you should definitely take in account when obtaining a token as well as when you issue a request.

[Oaden]

@andrewconnell

User.ReadBasic.All
User.Read.All
Group.Read.All

[GeorgiBoykov]

@justdevelopment said:

but surely they should then get the same access denied you get when your account has no access instead of just failing badly on a token request

Not necessarily... scopes are granted on a resource which is not the full URL of the endpoint, but rather the TLD (ie: graph.microsoft.com). At any rate, that (4** status code) is something you should definitely take in account when obtaining a token as well as when you issue a request.

Just to add here, that our issue is not related to Graph API, we get the same error, but while calling our own, Azure deployed Web Api secured with Azure AD from Guest accounts (Please see my previous post). The problem is either in the SPFx calling the Azure AD to authenticate or the Azure AD itself processing the auth request. I believe that the reason is in the fragmented UPN.

[andrew-lott]

We have seen the same issue as @GeorgiBoykov starting around 29th March, where external AAD (guest) users get the error when calling our own Azure AD authenticated Web API service via the AadHttpClient.

AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.

SharePoint Framework 1.7.1

[michel-weber]

We are having the same problem. That means three of our most-used applications have stopped working for guest users (they did work before)!

Scenario:
SharePoint Framework 1.7.1
Calling our own Azure AD authenticated Web API via the AadHttpClient.

[gurubn]

I can confirm the same behavior with SharePoint Framework 1.6.0.
Calling Azure AD authenticated Web API via the AadHttpClient and for guest users we are getting below error from March last week.

[LauraKokkarinen]

Any update on this? All of our SPFx web parts that utilize Microsoft Graph have stopped working for external users. Some of them have been working just fine since August, until now.

Posting my original report from another thread here as well:

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)

[patmill]

Sorry for the silence - we have a fix for this that we are getting submitted and rolled out. Will update when we have a more specific timeline.

[patmill]

This should be mitigated for now. Can you let us know if it is still occurring?

[gurubn]

Thanks a lot for the fix. I have tested my "SPFx web part consuming Azure AD authenticated Web API using AadHttpClient" and Its working now for guest accounts in our Production tenant.

[michel-weber]

We have tested our applications and we can confirm the fix is working for all affected applications. Guest users can once again access our AzureAD authenticated Web API through our SPFx Webpart.

[Ashish1662]

We have also tested our application and it is working again for the guest users.
Thank you all.

[akhilohri]

I am still facing the issue. Just tried testing with multiple office 365 accounts and i get the same error

[keschte]

@akhilohri it seems that you are confusing "Guest access" (This issue #3772 where a hotfix was rolled out by MSFT) vs. the other issue "Multiple Signed-in Accounts on OS-level" (#2629) which is still unresolved.

[Oaden]

Apologies for the late response,

I am getting reports from users that the issue still persists. I tested it, and i do still get the same error.

Logging in on a guest account, has the webpart throw the same error when trying to use the /teams/{groupid} endpoint

A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.

I am using the MSGraphClient, not the AadHttpClient

[DesireSwaroop]

I am facing same issue while using MSGraph API with SPFx Web part. We have developed a Web-part which sends the mail to user (Gmail Account) from External User Account. Is there is any update or fix for this issue?

[andrewconnell]

FYI @akhilohri @DesireSwaroop @Oaden

Commenting on a closed issue won't get much traction... if the issue is closed, suggest you submit a new issue with as much detail as possible so it can be appropriately triaged, tracked & addressed.

In addition, ensure you have read @keschte's comment https://github.com/SharePoint/sp-dev-docs/issues/3722#issuecomment-482457063

[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