"Application requested a user session which does not exist" and "Token request previously failed"

[kbeeveer46]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [X] 💥 Google Chrome
• [X] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• SPFx version 1.18.0
• Node.js version 18.17.1

Describe the bug / error

I know these 2 errors have been talked about a million times on here before but I've tried all the solutions that usually work and they are not working this time. When our clients have gotten these errors in the past it's always related to cookies. So this time around I had the client do the same thing as our previous clients that had the same issue.

• Delete all cookies
• Change the cookie settings in all browsers to allow third party cookies
• Turn off "enhanced tracking protection" in Firefox

But they keep getting those 2 errors no matter which browser they try. The error is occurring on the second line of the code snippet below. I have this code in a while loop that tries to get the token 3 times in case it fails (we've been having problems with the getToken method for various reason over the years). It fails all 3 times.

The client is able to view the SharePoint site so that tells me all the permissions are working correctly. The issue is happening after the page loads when we try to generate a token to use with our API calls to the database to load data on the page. So it has to be something on the client's end like an issue with cookies or a browser setting.

Am I missing any possible solutions? Can someone look inside that library and let me know all the reasons the code would spit out the "Application requested a user session which does not exist" error? It's almost impossible to fix the issue when I have no idea what causes the error.

EDIT: I was able to reproduce the exact same errors in the workbench in Chrome by blocking third party cookies. But what I found is that sometimes the page DID NOT do a full page reload to attempt the workaround/backup authentication when cookies are blocked. I think this may be the cause of the issue for the client. I think the authentication is failing and the backup option is also not working. It doesn't explain why they would be getting the errors in the first place when their IT staff said they changed the settings to allow cookies.

EDIT 2: We now have a second client who has the same issue.

EDIT 3: It seems to work for client 2 now. I had them do all the same steps as client 1. The issue is definitely related to cookies but it's hard to tell what actually fixes it. Maybe wiping all cookies is the thing that fixes it and client 1 didn't do it correctly.

EDIT 4: We're up to 5 clients now who are showing these errors in our logs within the past week. Was there a recent change behind the scenes regarding tokens? We're seeing the errors from Edge, Chrome, and Safari. All different clients.

Steps to reproduce

const provider = await this.context.aadTokenProviderFactory.getTokenProvider();

token = await provider.getToken(Settings.AZURE_SHAREPOINT_APP_REG_CLIENT_ID) ?? "";

Expected behavior

Return a token

[ghost]

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

[andrewpeterson99]

@kbeeveer46 did you ever figure this out? I'm running into the same issue.

[andrewpeterson99]

Pinging @nick-pape as well for this.

[kbeeveer46]

@andrewpeterson99 We have 1,400 external guest users that log into our SharePoint which we use for our client portal. We require the user to set up MFA with the auth app, phone call, or text message option.

• "Application requested a user session which does not exist": We get this one daily but I haven't seen any complaints from our users. It might just be something Microsoft logs when a user needs to re-authenticate?

• "Token request previously failed" and "Token renewal operation failed due to timeout.": These are the more serious ones that completely makes our SharePoint sites unusable. We used to get these errors daily but now I only see it a few times a week from different users each time. Without being able to generate a token we are not able to call our custom APIs to display data in SharePoint in our custom web parts. It's a single point of failure in our application. My assumption is that Microsoft's getToken API just randomly doesn't return a token and returns one of these errors. Our logs show that it happens in both Chrome and Edge. I haven't figured out why it happens or if there's anything we can do about it. It seems like it's on Microsoft's end. I am several people removed from our external users so I can't contact them and try to diagnose the issue.

I wish there was a place that explained all these errors. I have a list of 15 or so errors that Microsoft throws during SSO authentication and token generation (both single points of failure) and I can't tell if they are just informational or blocking things from working. The only ones that I know of that stops everything from working are the token errors above.

[andrewpeterson99]

Thanks so much for dropping an update @kbeeveer46. The situations we're seeing this error in is also rendering our Sharepoint integration completely broken. The strange thing is that we have only a subset of customers seeing the issue, but those that do encounter it cannot seem to get rid of it (e.g. the users who have the problem can't stop having the problem). Is this the behavior you're seeing on your end as well?

[kbeeveer46]

@andrewpeterson99 Since the last time I commented we've gotten the "Token renewal operation failed due to timeout" error once from a user within our company and 3 times from an external guest user (external user got them all within the same minute/browsing session).

According to our logs, the external user viewed our SharePoint site earlier in the day and didn't get the error. It only happened when they visited again later in the day.

I haven't found anything in common when the error happens. It happens for random users and when it happens it doesn't happen every time for that user.

[andrewpeterson99]

I may have made some progress on a fix, but I haven't been able to get a customer to verify the efficacy yet. I can repro the issue consistently for failing JWT requests if I don't grant all the API permissions in Sharepoint (specifically, access_as_user). The API permissions page for Sharepoint seems to be a bit buggy/have race conditions, as the UI there doesn't always reflect what's present in Azure for the app registration. Here are the steps I wrote up for our customers:

• Delete the integration from Sharepoint at https://{companyUrlHere}.sharepoint.com/sites/appcatalog/_layouts/15/tenantAppCatalog.aspx/manageApps (replace {companyUrlHere} with your Sharepoint URL)
• Delete the integration from Azure at https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade (make sure you're viewing the "All applications" tab)
• Reinstall the Sharepoint integration
• Wait ~2mins after installing
• Approve the API permissions at https://{companyUrlHere}-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement (replace {companyUrlHere} with your Sharepoint URL)
• Go to the Azure portal again and click on the integration. Confirm that the API permissions include access_as_user and User.Read (see screenshot; my instance only has access_as_user, but you should have both after approving all the pending API permissions).
• Try to use the integration as normal on a Sharepoint page by adding it

You could try this in the instance where your internal repro occurred and see if it fixes it? Some direction from @nick-pape or MS on this would be super appreciated.

[kbeeveer46]

@andrewpeterson99 I'm not sure what "access_as_user" is. We do not use a permission by that name. Is it the same thing as user_impersonation? The app registration that our SharePoint webparts use to make API calls and generate tokens has the user_impersonation permission (and User.Read). The permission is listed under the app registration

It's also under the approved list on the API permission page (the link in your 5th bullet point) and in the package-solution.json file in our app

"webApiPermissionRequests": [          
            {
                "resource": "ClientPortalSharePointAPI",
                "scope": "user_impersonation"
            }
        ]

It looks like our scenarios might not be the same but resulting in the same error message. I don't have permissions to approve API permissions so I can't run your test.

[andrewpeterson99]

Here's a link that makes it sound as though we just have different custom names (and the checking against them is what matters more than the name itself): https://github.com/Azure-Samples/active-directory-dotnet-native-desktop/issues/36

[Amey-MSFT]

Hello @kbeeveer46, Thank you for bringing this issue to our attention. Could you please confirm if the issue still persists for you?