SharePoint folder application permission assignments: does delegated Files.ReadWrite plus human ownership suffice?

Delegated Files.ReadWrite plus the signed-in user’s site ownership should not be treated as a documented-supported authorization combination for creating SharePoint Online folder application assignments; the two applicable Microsoft references give overlapping but unresolved requirements.

Where the documentation conflicts

The v1.0 create-permission reference says:

• Files.ReadWrite is the least-privileged delegated permission for work or school accounts.
• For SharePoint Online, this endpoint creates only application permissions.
• The request must use grantedToV2.
• A successful request returns 201 Created. ^1^

That directly describes your endpoint and payload:

POST /v1.0/drives/{drive-id}/items/{folder-id}/permissions
Content-Type: application/json

{
  "grantedToV2": {
    "application": { "id": "{runtime-client-id}" }
  },
  "roles": ["write"]
}

However, the Selected-permissions overview separately defines the authority required to manage permissions on a file-level resource, which includes a document-library file or folder. Its supported authorities are:

• Sites.FullControl.All; or
• Sites.Selected with Owner or FullControl assigned on the parent site; or
• Lists.SelectedOperations.Selected with Owner or FullControl assigned on the parent list/library.

For delegated calls, the signed-in user must additionally have sufficient SharePoint permission to manage access. ^2^

Files.ReadWrite does not appear in that management-authority table. The overview also does not say that this table applies only when the provisioning client itself uses a Selected scope. Consequently, the documentation does not confirm that human site ownership substitutes for the provisioning application’s documented parent-resource authority.

The safest documented conclusion is therefore:

• Files.ReadWrite is confirmed as the endpoint-level delegated scope in the POST reference.
• Sufficient user authority is an additional delegated requirement.
• Whether those two facts alone override the stronger parent-resource requirements in the Selected-permissions overview is not resolved by the official documentation.
• Production use of that narrow combination requires authoritative clarification from Microsoft; otherwise, a 403 remains possible and the design cannot be represented as documented-supported.

Documented supported model

If the parent-resource requirement is accepted, the separate provisioning client must use one of the authorities in the management table, while the human caller must also have sufficient SharePoint authority. The runtime applications then need:

1. Delegated or application Files.SelectedOperations.Selected consent.
2. An explicit read or write assignment on the folder.
3. A token containing that Selected scope when accessing the assigned folder.

All three are required. In delegated runtime use, effective access is the intersection of the application’s permission and the signed-in user’s permission. Folder assignments also break permission inheritance and create a unique permission scope. ^2^

Because your constraints exclude tenant-wide scopes and parent Owner/FullControl assignments, the reviewed official documentation establishes no supported Graph provisioning path satisfying all those constraints.

List, retrieve, and delete authority

For the driveItem permission surface:

GET /v1.0/drives/{drive-id}/items/{folder-id}/permissions

DELETE /v1.0/drives/{drive-id}/items/{folder-id}/permissions/{permission-id}

Successful deletion returns 204 No Content. ^4^

The cited v1.0 driveItem documentation establishes collection listing but does not document a corresponding driveItem GET .../permissions/{permission-id} operation. Store the permission ID returned by POST, or locate it through the collection listing before deletion.

Human-admin alternative

The reviewed Microsoft documentation does not identify a SharePoint, Microsoft 365, or Entra UI that creates a folder assignment whose principal is grantedToV2.application. Ordinary SharePoint sharing UI is not documented as an equivalent application-assignment mechanism.

Therefore, no Microsoft-native human-admin procedure is established here that both:

• uses only the administrator’s existing human authority, and
• avoids broad or parent-resource authority on the provisioning application.

That is a documented gap rather than proof that no internal or future mechanism can exist. Under the currently documented model, your requested narrow design remains unsupported/ambiguous rather than confirmed least privilege.

References

1. Create permission on a driveItem
2. Overview of Selected permissions in OneDrive and SharePoint
3. List sharing permissions on a driveItem
4. Delete a sharing permission from a file or folder