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.
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.
"displayName": "Foo App"
The available roles are:
|Adds Write and related bits
|Adds Manage Lists / Designer and related bits
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.