Sp-dev-docs: Silent sign Error when trying to access graph and azure functions in inkognito and InPrivate mode

[MagtheRag]

Category

• [x] Bug

Sometime in June this error start to appear.
When browsing in inPrivate mode (Edge) or Ikognito mode (Chrome) and trying to access either the graph or Azure through the authenticate providers given from spfx (msGraphClientFactory, aadHttpClientFactory) it fails everytime.
The console will give you the following error:

Uncaught (in promise) Error: login_required: 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).
Trace ID: 5e793169-4381-4c9b-85ef-5c7fc9f51200
Correlation ID: a3bd250b-2bd6-4ffc-9b6b-9600fc943ba2
Timestamp: 2020-08-18 08:00:59Z

It works like a charm when not in InPrivate mode or Ikognito mode

Steps to reproduce

Any solution trying to access the graph or an Azure funtion will fail in InPrivate mode or Ikognito mode

Expected behavior

It should work as when you are browsing in "normal" mode. This is really critical for us as many people uses the iknognito because they are often between different accounts, tenants in Office 365 and the solution FAILS totally.

Environment details (development & target environment)

• Your Developer Environment: MacOS 10.15.5
• Target Environment: SharePoint Online
• Framework: Node.js v10.13.0
• Browser(s): Chrome v83.0.4103.116 | Chromium Edge v81.0.416.68
• Tooling: VS Code | SPFx v1.11.0
• Additional details: We are running a solution that uses the spfx providers. The solution itself is using vue but this should not be a problem.

[msft-github-bot]

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

[joebergqvist]

Same issues seen in several customers Tenants

[patmill]

We're aware of issues around incognito / in-private-browsing / safari ITP. Working hard on a solution. Will post when we are rolling it out.

[michelsmit]

Having the same issue on MacOS in Safari using the 'Prevent Cross Site Tracking' setting. Every call from our custom SPFX webpart fails.

Please come up with a solution soon since it renders all our webparts unusable with a client working from Apple devices.

[kunalkankariya]

Meanwhile, you can use msal-browser to implement authentication / authorization. This works in incognito mode as well as it uses Auth code flow with PKCE and not the usual implicit grant flow.

https://m365.kksimplifies.com/rvmLkE

[reiniersmit]

Any news to share on this issue? A couple of our clients are affected by this issue and cannot use Safari with cross-site tracking enabled.

[reiniersmit]

The issue we have on MacOS in Safari using the 'Prevent Cross Site Tracking' setting which results in every call from our custom SPFX webpart to fail was resolved last week. But for some reason the fix has been pulled again. This happened on our tenant and the tenants from our clients. Any news to share on the progress?

[tdwhite0]

I'm seeing an issue like this too. I have SPFX WebParts using the built in SPFX AadHttpClient that were working until I logged in today on iOS Safari and started seeing a yellow banner that says "To view the information on this page, you need to verify your identity. Click to provide additional credentials.". Calls to get a token using AadHttpClient fail and error out. When I actually click it and reenter the credentials, the page reloads but the banner does not go away, and the calls still fail. If I disable the "Prevent Cross-Site Tracking" setting on the phone, the problem goes away.

I know the changes to iOS and ITP are the problem. Since this was working up until now it does seem like something changed with how SP is handling it. I thought it could be the recent iOS 14 update that triggered the problem, but I tested with a colleague still on iOS 13. I have been investigating the workarounds using msal-browser, but its non-trivial to implement with multiple WebParts because they can't all have their own instances of MSAL, I need an extension to handle a global instance. There is also the problem of if my WebPart does need to redirect you to the AAD app's redirect uri, I can't have a dynamic reply url.

@patmill should I be trying to build a workaround using MSAL JS 2.0 and PKCE like the link posted by @kunalkankariya or is this coming to SPFX soon? I'd love to be wrong but it seems like there's no way to way to make iOS clients work with the built in AadHttpClient.

[kunalkankariya]

@tdwhite0 - You shouldn't have any issue with the redirect URL. Point it to the workbench and it will do the rest. It needn't be dynamic. However, you might have issues if you have multiple webparts on the same page (I haven't tested it yet and didn't work on finding any solution for this yet).

[MarkyDeParky]

As of today, I can confirm it's still an issue at our tenant (and at least at one of our clients' too).

As a proof of concept I fabricated a little web part to try out @kunalkankariya 's solution for using MSAL v2 and compare it to default SPFx MSGraphClient (ADAL). The results were as expected:

In Safari, with 'prevent cross-site tracking' enabled, ADAL fails where MSAL v2 works:

In Chrome, where I have no such restriction enabled, both work fine:

I work for an ISV where we've built a solution that relies heavily on communicating with the MS Graph and up till now we've always been doing this using SPFx's standard approach (based on ADAL). We're now facing the fact that some clients are starting to report issues using our solution in Safari (either on Mac but also on iPad and iPhone). Up until now we've been telling our clients that Microsoft is working on this issue and that we're waiting for a solution as well. But it's really taking long and it becomes harder and harder to keep our clients' trust.

Of course we could fix this issue (maybe temporarily) by implementing the MSAL v2 library in our solution ourselves, but this requires a lot of effort (probably weeks of development and testing). I'd rather not do this but as said, it should not be in this state for much longer.

@patmill or maybe @VesaJuvonen or @lucabandMSFT could you please give some information regarding the timelines on what you've been working on regarding this? Is a fix or solution 'around the corner' or should I start implementing MSAL v2 myself?

Mark

[patmill]

Hi @MarkyDeParky / @tdwhite0 - sorry for not responding earlier. The fix is understood and has been made, and is pending a rollout. The latest build was pulled back for an unrelated manner, but should start rolling again today I believe. You should have the fix next week.

[MarkyDeParky]

Now that the fix (or 'patch' as I now prefer to call it) has been available for about a week, I would like to share my experience with it so far and also ask for some help/clarification:

What's happening from an end user's perspective now that the fix/patch has been rolled out is the following:

1. In Safari (or an incognito window in Chrome for instance) I go to a SharePoint page with a web part that connects to the Graph REST API
2. The API call fails (upon this first visit) with the following exception caught: "Please set the correlationId as a valid guid" (errorCode = invalid_guid_sent_as_correlationId). Right now, our solution handles all exceptions the same by showing an error message to the user.
3. In the background (outside our control) a page refresh is somehow triggered, probably by the fix/patch. This takes up to a second to actually happen, so our error message is displayed for a split-second, possibly confusing the user.
4. The page is fully reloaded and the Graph API call now works correctly

Unfortunately, as soon as I close and re-open the browser (or open a new tab for that matter), the whole process is repeated: It didn't 'remember' the authentication so it goes through the reloading process again.

The situation is different (even less ideal) when we not only connect to the Graph, but also to other REST API's like Power BI and Windows Virtual Desktop. In that case, the browser does multiple consecutive reloads for each API call that's done to a different REST API.

I could really use some help or clarification on the following topics:

• Is the described behavior correct and is this how the fix was indeed implemented and supposed to work?
• Is there any way to properly detect that this refresh is happening so I know that I shouldn't treat this scenario as an exception (and in turn show an error message that confuses the end user)?
• Is this fix 'here to stay' or will the authentication issue be resolved in the future without the need to do reloads/refreshes? I've heard about the shift from ADAL to MSAL by the SPFx/PnP team but I'm not sure of the timelines and the impact on me as a developer to make this work in my existing solutions

Although our solution is now at least somewhat usable, the situation is still far from ideal. The multiple reloads each time a user (re)visits the page with our web part is pretty annoying but confusing for our end users at the least.

Please advise.

Mark

[nflourens-dev]

We decided to build our own library for resolving access tokens for communicating with Azure AD protected endpoints. This library is based on MSAL v2 and supports the ITP scenario (3rd party cookie blocking). We have ensured this implementation can handle scenario's when there are multiple webparts on the same page each requesting a token for making an authorized HTTP request to our backend Azure App Service.

I am aware of the fact that this internally developed library becomes useless when Microsoft comes with a better solution handling the concurrency problems which do exists in the current version as mentioned in this topic (or other related ones).

[kenneho]

1. In Safari (or an incognito window in Chrome for instance) I go to a SharePoint page with a web part that connects to the Graph REST API
2. The API call fails (upon this first visit) with the following exception caught: "Please set the correlationId as a valid guid" (errorCode = invalid_guid_sent_as_correlationId). Right now, our solution handles all exceptions the same by showing an error message to the user.
3. In the background (outside our control) a page refresh is somehow triggered, probably by the fix/patch. This takes up to a second to actually happen, so our error message is displayed for a split-second, possibly confusing the user.
4. The page is fully reloaded and the Graph API call now works correctly

Hi @MarkyDeParky, this sounds like the same issue we have in our custom SPFx solution. Did you ever find a workaround for it?

[MarkyDeParky]

Hi @kenneho, unfortunately I haven't received any feedback and since we're still experiencing this behavior at this day, a reply is still very much welcome.
@patmill, you replied before, could you please answer my questions/address our concerns?

Mark