Anonymous sharing link opens fine but user-specific edit link fails with Access Denied in same browser session

Question

Anonymous sharing link opens fine but user-specific edit link fails with Access Denied in same browser session

Prajwal K Divate 0

Hi everyone,

I'm building an application that uses Microsoft Graph API to generate two different types of sharing links for two different files on the same SharePoint site. The setup is working fine in isolation, but I'm running into a weird issue when both links are opened sequentially in the same browser session.

Here is what my app does:

Creates an anonymous (scope: "anonymous") edit link for File A using the createLink API
Creates a user-specific (scope: "users") edit link for File B, granted to a particular email (user@example.com)

The API calls are succeeding and I'm getting valid 200/201 responses for both. The anonymous link works fine. But here is the problem, once the user opens the anonymous link in a browser, and then tries to open the user-specific edit link in the same browser session, they get the "You can't access this site – You don't have permission to access this item" error screen from Microsoft. See screenshot below:

User's image

If I open the user-specific link first (before the anonymous one), it works perfectly. If I open it in a fresh browser / incognito window, it also works. So the issue is clearly happening because of the anonymous session that gets established when File A's link is opened.

For reference, here are the API calls I'm making:

For the anonymous link (File A):

POST https://graph.microsoft.com/v1.0/drives/{driveId}/items/{itemId}/createLink


{

  "type": "edit",

  "scope": "anonymous",

  "retainInheritedPermissions": false

}

0 comments

1 answer

Your answer

Answer 1

Gabriel-N 17,785 Microsoft External Staff Moderator

Hello @Prajwal K Divate

Based on my research, when a user opens an anonymous sharing link (scope: "anonymous"), SharePoint establishes an anonymous session in the browser and stores this context using cookies. Any subsequent requests in the same browser session continue to operate under this anonymous context.

When the user then tries to open a user-specific link (scope: "users"), SharePoint expects an authenticated identity that matches the user the link was granted to. However, the browser is still using the anonymous session, creating a mismatch. This results in the “You don’t have permission to access this item” (or “You can’t access this site”) error.

This behavior is consistent with SharePoint’s session-identity handling: access fails when the current session context does not match the account the link was granted to.

As practical workarounds, you may consider:

Open the anonymous link in a separate browser context (new window, incognito/private mode, or different browser/profile).
Open the user-specific link first, then the anonymous one (the reverse order avoids the conflict).
Ensure users are fully authenticated (signed in with the correct account) before opening the user-specific link.
Avoid mixing anonymous and user-specific links in the same user flow if possible.

I hope this clarifies the behavior.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Gabriel-N 17,785 Reputation points Microsoft External Staff Moderator

2026-05-21T10:12:36.1533333+00:00

Hello @Prajwal K Divate just following up to see if the information above was helpful. If you have any updates or further questions, feel free to share them here.
Prajwal K Divate 0 Reputation points

2026-05-21T11:30:01.45+00:00

@Gabriel-N

Thanks for clarifying. In our platform, users can create both public and private SharePoint links as part of the normal workflow, so asking them to use incognito, a different browser, or open links in a specific order isn’t really practical. Is there any supported way to handle this properly?
Gabriel-N 17,785 Reputation points Microsoft External Staff Moderator

2026-05-21T11:59:44.84+00:00

Hi @Prajwal K Divate

Thank you for your feedback. Please allow me some time to review this further, and I will get back to you as soon as possible.
Gabriel-N 17,785 Reputation points Microsoft External Staff Moderator

2026-05-22T15:04:01.8+00:00

Hi @Prajwal K Divate

I don't have the exact set up in your platform, but you may consider using the /invite API instead of createLink with scope: "users". With /invite, you assign permissions directly to the target user, and then provide the standard webUrl of the file or folder (via GET /drives/{driveId}/items/{itemId}). This avoids relying on a special “users-scope” sharing link and in many cases behaves more consistently with normal authenticated access patterns.

Beside, it’s important to note that this does not fully eliminate session-related behavior, since SharePoint still relies on the browser’s authentication context. However, in practice, it can reduce some of the friction compared to mixing anonymous and user-scoped links.

In addition, it’s worth verifying whether the “Limited-access user permission lockdown mode” site collection feature is enabled. This feature can sometimes introduce unexpected permission behavior, especially in scenarios involving mixed sharing models (anonymous + specific users). If it is enabled, you may want to test by temporarily disabling it at:

Site Settings > Site collection features > Deactivate “Limited-access user permission lockdown mode”

Overall, while these approaches may help improve consistency, there is still an underlying platform limitation around session handling in SharePoint Online. So testing these options in your specific flow will be important to see how much they mitigate the issue. For more targeted and in-depth assistance on your specific architecture and scenario, I would also recommend reaching out to Microsoft Support so they can investigate further from the backend and confirm whether there are any tenant-level behaviors or service-side limitations involved.

As this is a user-to-user support forum, moderators like myself are not part of Microsoft Support and do not have backend access to investigate or make changes within the service. We can only provide technical guidance and best-practice recommendations based on publicly available information and similar reported scenarios.

Share via

Anonymous sharing link opens fine but user-specific edit link fails with Access Denied in same browser session

1 answer

Your answer