Sp-dev-docs: MSGraphClient Error AADSTS50058

[schurlinga]

Category

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

We have a webpart which is using MSGraphClient. Everything is working as expected, except if you don't close the sharepoint site including the webpart and the browser over night, the next day you will receive the error: AADSTS50058: A silent sign-in request was sent but no user is signed in

Even though it says "no user is signed in" it is possible to browse every sharepoint online site without hitting a login screen.

Errors thrown:

• AADSTS50058: A silent sign-in request was sent but no user is signed in
• Refused to display 'https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&redirect_uri=https%3A%2F%2Fwebshell.suite.office.com%2Fiframe%2FTokenFactoryIframe&state=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&client-request-id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&x-client-SKU=Js&x-client-Ver=1.0.15&nonce=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' in a frame because it set 'X-Frame-Options' to 'deny'.

Expected or Desired Behavior

As the webpart is embedded on a sharepoint site, there should be no error saying "no user signed in".
The MSGraphClient should handle this error internally by initiating all steps necessary to log in the user again.

Observed Behavior

Microsoft Graph resources can't be accessed due to silent sign-in error

Steps to Reproduce

1. Create a SPFx1.6 webpart solution
2. Use MSGraphClient to access graph resources
3. Login to SharePoint Online site where the webpart is added
4. Leave the site open and untouched over the night
5. Come back the next day and refresh the page -> AADSTS50058: A silent sign-in request was sent but no user is signed in

SPFx version 1.6.0
SharePoint Online Standard Release
Browsers:

• Chrome Version 68.0.3440.75 (Official Build) (64-bit)
• Internet Explorer 11

[schurlinga]

As a workaround we can redirect the user to:

`https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=domain.com&wreply=${window.location.href}`

[gagan2singh]

Do we have any update on this. We are also facing the same issue. Closing all the browser and opening it again works sometimes.

[maps05]

Just to add that I'm having the same issue in SPFx1.7 extension. Also interested in the outcome of this.

[aslanovsergey]

Yeah, confirm. After a user hibernates their computer or turns into sleep over night the next day they get Error: AADSTS50058: A silent sign-in request was sent but no user is signed in.
Would be nice if it will send to Sign-in page.

[MatthiasWeibel]

Is there any update on this issue? Are you able to provide an estimated release date of a fix?

[dashberg]

Same goes for AadHttpClient in Chrome -SPFx1.7 Webpart. After token expire users need to reopen the browser.

[MarkyDeParky]

We have this exact issue in our Graph-powered web parts based on SPFx 1.8.1.

As soon as a user refreshes a browser window that was open over night, the Graph-calls fail and raises the error AADSTS50058: A silent sign-in request was sent but no user is signed in.

Some more details about what we've found out so far:

• Navigating to Delve or logging in to the Graph Explorer fixes the issue for that day
• Navigating to https://tenant.sharepoint.com/_forms/default.aspx?returnUrl=https%3A%2F%tenant.sharepoint.com%2Fsites%2Fsite fixes the issue for that day
• It appears that for some users restarting the browser fixes the issue as well, but that might be because the navigate to the site in a different way
• We've seen the issue both in IE 11 and in Edge
• (At least) one user has this issue even after shutting down her computer and restarting the next day, opening a new instance of the browser after booting
• Because of some SSO configuration, users don't get to see the window where they get to check the KMSI (Keep Me Signed In) checkbox. Could it be that this causes the authentication cookie to expire?
• We've got Conditional Access configured. Not sure what this has to do with the issue but we only have the issue in our 'production' tenant, where this is set up, and not in our test tenant, so maybe it's related...
• (At least) one user was having a different error: AADSTS50158: External security challenge not satisfied. It's unclear what caused this specific error...

For now the workaround is to detect the error and redirect the user to the above url, but it would be great if it's somehow fixed in ADAL or PnP JS...

[Hatallia]

We are having the same issue with SPFx 1.8.1. We are using Graph API in the web part and receiving the same error over the night if the browser was not closed. More details from our end: in addition to the "AADSTS50058: A silent sign-in request was sent but no user is signed in" there is also an error message that we caught regarding the token renewal: "Token Renewal operation failed due to timeout". The adal.error variable in Local Storage is saying that "Login is required".

[ghost]

We made a recent change to the service that prompts the user with the following message
"To view the information on this page, you need to verify your identity. Click Here"

Do you see this behavior? Does it resolve the silent sign-in error?

[andygjones-nz]

We made a recent change to the service that prompts the user with the following message
"To view the information on this page, you need to verify your identity. Click Here"

Do you see this behavior? Does it resolve the silent sign-in error?

After this change we started seeing an alert for each web part on the page (only for certain users in IE). Our ICT team solved it by adding the following to trusted sites in IE
https://graph.microsoft.com
https://.office365.com
https://.microsoftonline.com
https://.sharepoint.com
https://.outlook.com

[wpo365]

We (a large enterprise company with 30K employees) are experiencing the same issue. We have implemented the aforementioned work-around (redirecting the user via https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=domain.com&wreply=${window.location.href}). Unfortunately, the work-around doesn't seem to work for iPhone and Mac (Safari) users. After redirecting those users the popup re-appears. And more in general, the work-around also negatively impacts the performance (due to a number of redirects being added to the request).

We are indeed using SPFx 1.6, calling Graph using the MSGraphClient and the error reported by Safari is the same as stated previously in this thread, namely Error: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com).

@VesaJuvonen Is there any chance you can give an estimate as to when this can be fixed and also whether it would be possible to push the fix to older versions, most preferable to 1.6.x?

[wpo365]

@lahuey @VesaJuvonen Why has this bug been closed? It is by no means resolved or if it has it doesn't follow from this issue. The alternative is that we open a premier support ticket instead - but as far as I can see this issue was marked bug:confirmed only ~30 days ago. Or do I need to open a new issue which is identical to this one but specifically mention that the issue occurs on Safari on iPhone / Mac?

[ghost]

@wpo365 It seemed like the recent fix unblocked customers that were affected by this problem. If you're seeing this issue occur on Mac/IPhone Safari consistently, could you create a new GitHub issue with the specific details/repro steps for your problem. We would love to take a look at this issue.

Thanks!

[gschwendt]

Just to add to this, I've had a handful of users experiencing this same issue not only in Edge but also in Firefox and Chrome.

It seems as though adding the Trusted Sites listed above into Internet Explorer solved the cases in a handful that I could test (including in Firefox and Chrome). Previously when a user received that message, even if they went through the steps to re-sign in, it would return to the same error. However, after adding the Trusted Sites in IE, the user may receive that message initially but after re-signing in, the web part will work properly.

For context, I'm on SPFx 1.8.2, this is a Graph call to Users.Read.All and this is on a Classic SharePoint page.

[JBoman32768]

Can reproduce this on Edge 44.18362.1.0 - but not on Chrome or the new Chrome-based Edge.
Get the new "To view the information on this page, you need to verify your identity" banner every time on Edge - not on the other browsers.
Have tried the trusted sites in IE changes above, but had no effect.

[gschwendt]

I still seem to be getting this on a user-by-user basis after a few weeks or so (browser does not matter, have seen in Edge, Firefox, & Chrome). It seems as though a token or session times out and it asks the user to re-validate by signing in. However, if you don't use the web part that makes the Graph call, you are not prompted to re-sign in.

[sergekhakhin]

I get _"To view the information on this page, you need to verify your identity."_ every time I open a shared link (Chrome 77.0.3865.90). When I open the link in IE11—it works smoothly without any popups.

[MRuimerman]

We see the same thing happening sometimes.

[jduiella]

I also experienced the error To view the information on this page, you need to verify your identity.Click to provide additional credentials. when using a web part that used Microsoft Graph:

⚠️ I was only able to produce the error when the users browser settings prevented third-party websites from saving and reading cookie data

Error message and screenshots from Chrome

[lworkman]

Just popping in here to say I've seen this show up in multiple tenancies, devices, and browsers. It'd be great if, at least, the link worked.

Commenting in here as it seems to be the most active ticket related to the issue (#4363 has been closed).

[MatthiasWeibel]

@lahuey why was this issue closed? It definitely seems that a lot of environments are still suffering this issue. I suggest to reopen it and take care after this issue.

[grooveska]

This issue is happening here for us as well in the Sharepont App in iPadOS 13. Going to try a few of the fixes mentioned in a couple of posts and then submit a ticket to Microsoft.

[PeppeDotNet]

We have exactly the same issue, but only for federated users. Cloud only users work as expected. It can be something related to the configuration of ADFS?
Do you guys have ADFS configured for SSO?

[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