Microsoft Graph: link.webUrl omitted from DriveItem permissions with app-only Files.ReadWrite.All / Sites.ReadWrite.All

Question

Microsoft Graph: link.webUrl omitted from DriveItem permissions with app-only Files.ReadWrite.All / Sites.ReadWrite.All

Saar Mansharov 5

Our application uses Microsoft Graph with app-only authentication (client credentials) to retrieve sharing permissions for DriveItems stored in OneDrive for Business / SharePoint Online.

We retrieve permissions using:

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id}/permissions

The request succeeds with 200 OK, and the sharing permissions are returned. However, for permissions containing a link facet, the link.webUrl property is omitted.

Environment

Microsoft Graph
App-only authentication / application permissions
OneDrive for Business / SharePoint Online
Application permissions:
- Files.ReadWrite.All
- Sites.ReadWrite.All

According to the List sharing permissions documentation:

Sharing permission properties that contain secrets (for example, shareId and webUrl) are only returned for callers that are able to create the sharing permission.

The Create sharing link documentation lists the following application permissions:

Least privileged: Files.ReadWrite.All

Higher privileged: Sites.ReadWrite.All

Since the application has both permissions, I would expect it to be considered able to create sharing permissions and therefore receive link.webUrl.

After i granted Sites.FullControl.All to the app the same request returned link.webUrl as expected.

Because Sites.FullControl.All provides significantly broader access, we would prefer not to grant it unless it is actually required.

Troubleshooting performed

I tested both Microsoft Graph versions:

v1.0

beta

I also tested both:

GET /drives/{drive-id}/items/{item-id}/permissions

and:

GET /drives/{drive-id}/items/{item-id}/permissions/{permission-id}

The behavior is consistent across all four cases.

Request IDs:

[Moderator note: personal info removed] - v1.0 permissions list
[Moderator note: personal info removed] - beta permissions list
[Moderator note: personal info removed] - v1.0 single permission
[Moderator note: personal info removed] - beta single permission

Is Sites.FullControl.All currently expected to be required for an app-only request to recieve link.webUrl, despite Files.ReadWrite.All / Sites.ReadWrite.All being sufficient to create sharing links according to the documentation?

If Sites.FullControl.All is not intended to be required, is there a supported way to retrieve link.webUrl using the documented lower-privilege application permissions?

0 comments

1 answer

Your answer

Answer 1

Hi @Saar Mansharov

As a fellow user like you, I can confirm the current behavior based on my testing.

With an app-only token using Files.ReadWrite.All + Sites.ReadWrite.All, the sharing-link permission is returned successfully, but the sensitive properties shareId and link.webUrl are omitted.

After adding Sites.FullControl.All, I repeated the same test against the same file and same sharing permission, and both shareId and link.webUrl were returned.

So, the behavior I observed is:

Files.ReadWrite.All + Sites.ReadWrite.All > link is returned, but shareId and link.webUrl are omitted.
Adding Sites.FullControl.All > shareId and link.webUrl are returned.

This appears to be consistent with what you are seeing.

However, I would not conclude that Sites.FullControl.All is officially required. The Microsoft Graph documentation for listing permissions says that sensitive properties such as shareId and webUrl are returned to callers that are able to create the sharing permission. The Create sharing link documentation lists Files.ReadWrite.All as the least-privileged application permission and Sites.ReadWrite.All as a higher-privileged permission. Therefore, based on the testing, this looks more like a difference between the documented permissions and the current service behavior for app-only access, rather than a documented requirement to use Sites.FullControl.All.

Since Sites.FullControl.All provides considerably broader access, I would avoid granting it in production solely to work around this behavior unless Microsoft confirms that it is currently required. As this is just a user-to-user support forum, I recommend raising the issue in the Microsoft Graph GitHub repository so that the product engineering team can investigate the behavior directly.

Reference: Participating in a discussion - GitHub Docs

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