SharePoint now supports delegated Sites.Selected authentication
In 2021, we introduced the Sites.Selected scope and capabilities allowing for an application’s access to be limited to specific site collections. This came with the limitation that it only applied to application-only authentication scenarios. This was a critical first step, and today we are excited to introduce support for delegated Sites.Selected scenarios.
This increases trust in applications as they cannot exceed the user’s existing abilities. As with other delegated scopes the minimal intersection of application and user permissions is used. Increasing the ability of admins to control application access to specific site collections and require user presence/access is another step in the trust journey crucial to our partner ecosystem.
Assignment
In scenarios where an application is consented to the delegated Sites.Selected scope, the “selecting” of sites remains the same. A POST request to the given site’s /permissions endpoint indicating the app id and role to assign.
POST https://graph.microsoft.com/v1.0/sites/{siteId}/permissions
Content-Type: application/json
{
"roles": ["write"],
"grantedToIdentities": [{
"application": {
"id": "89ea5c94-7736-4e25-95ad-3fa95f62b66e",
"displayName": "Foo App"
}
}]
}
The available roles are:
| Role Name | Meaning |
| read | Read-only |
| write | Adds Write and related bits |
| manage | Adds Manage Lists / Designer and related bits |
| fullcontrol | All permissions |
How do the two scopes interact?
Given that there is now a delegated and application only Sites.Selected scope, what happens if an application is consented to both? The answer is they both work. There is no distinction made when the application is assigned through the /permissions endpoint – you still assign only the application id and role. The distinction is made by the application when the token is requested – that determines if the token is application or delegated. When the call is made the permissions are calculated either as application or delegated, and assuming the request is authorized it will go through.
If you want to ensure a user is always present when an application accesses a site, only consent to the delegated option for Sites.Selected, this will block application-only calls.
Find more information in the SharePoint Developer documentation.
Follow us on X (Twitter) / @Microsoft365Dev and subscribe to our YouTube channel to stay up to date on the latest developer news and announcements.
Light
Dark
5 comments
Hi Patrick,
adding delegated Sites.Selected permissions is very welcome! This should make discussions with our customers easier when it comes to consenting our apps’ permissions.
Currently I can find Sites.Selected in the list of delegated Graph permissions but not in the list of delegated SharePoint permissions.
Do you have an ETA for delegated Sites.Selected permissions in the SharePoint API?
We use a mixture of Graph, REST and even CSOM to access SharePoint, because Graph is lacking some APIs when it comes to SharePoint access. So, we hope Sites.Selected is not Graph only?
Hi Patrick,
do you have any information, if delegated Sites.Selected permissions for SharePoint REST are coming as well?
We are also keen to know if delegated Sites.Selected permissions are coming to the SharePoint REST API?
At ESPC it was mentioned that the Graph API was the initial target for this permission but based on the wording it suggested it was coming to the SharePoint REST API.
The endpoint https://graph.microsoft.com/v1.0/search/query does not function with Sites.Selected permissions alone. The search functionality necessitates either Files.Read.All, Sites.Read.All, Files.ReadWrite.All, or Sites.ReadWrite.All permissions.
When an Azure application is granted Sites.Read.All and Sites.Selected permissions, it conducts searches everywhere rather than confining the search scope to Sites.Selected. Is this behavior indicative of a bug?
Looks like it works up to ‘https://graph.microsoft.com/v1.0/sites/{site-id}/’ but ‘https://graph.microsoft.com/v1.0/sites/{site-id}/lists/’ and anything more either returns no data or returns a 403/accessDenied.