Securing application access to SharePoint through Azure AD is easy. But often enough, these applications have far too much permissions. Do you really want to give an application access to your entire SharePoint tenant if it’s not necessary? This post is about how to let applications access SharePoint using the principle of least privilege.
Many companies employ them: solutions with standalone applications that execute a certain task. For example, automating the creation of SharePoint sites or enriching files with certain metadata. Many of these applications are configured to have permissions that are broader than what they actually need, for example
This setup is reached through a few clicks of a mouse. After adding a certificate, this application can access the entire SharePoint tenant, which is convenient, but dangerous as well. It essentially has what I would call: ‘God mode’ on SharePoint. It’s just slightly short of being a ‘SharePoint Administrator’. This means that the keys to the kingdom are effectively handed over to the Developers who created the application. If they make a mistake, the entire SharePoint tenant might be impacted.
As long as you’re not provisioning entire sites, you don’t actually need this level of permissions. In those cases there is another way: tone down on the permissions using Resource Specific Consent (RSC). Resource Specific Consent means just what it sounds like: instead of assigning permissions to the entire tenant, you can assign permissions to specific resources. In the case of SharePoint these resources are sites. RSC is a step in the direction of more granular permission controls.
Configuring RSC starts with creating/updating an Azure AD application registration with the permission scope
As you can see RSC for SharePoint comes in two flavors: Microsoft Graph and SharePoint. The level of permissions that are granted is the same, the difference lies in what API the programmers are intending to use: The Microsoft Graph API or the SharePoint REST API.
Important to note is that we’ve only registered the necessary scope for RSC in step 1. This was easy. However, there’s currently no place in the UI of Azure AD or SharePoint to configure what sites you want the application to have access to. This can be done by issuing requests against the Microsoft Graph API. For this post we’ll take another route though: assign the permissions using scripting.
Using the CLI for Microsoft 365 we can grant permissions in the following manner:
m365 login m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission fullcontrol --siteUrl "https://contoso.sharepoint.com/sites/project-x"
The above script needs to be run with appropriate administrative permissions. You need to be a
site collection admin on the site you are executing the script on.
You can also:
# List the existing app permissions that are assigned to the SharePoint site: m365 spo site apppermission list --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x" # Update existing permissions to another permission type: m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission read --siteUrl "https://contoso.sharepoint.com/sites/project-x" # Remove the assigned app permissions from the SharePoint site: m365 spo site apppermission remove --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x"
There’s currently four types of permissions that can be granted. They match the available app-only scopes in Azure AD:
- read - Read items in a site collection
- write - Read and write items in a site collection
- manage - Read and write items and lists in a site collection
- fullcontrol - Have full control of a site collection
If you are more into using PnP.PowerShell , you can achieve the same. But you need to execute two commandlets. First grant
Write permissions. Then update it to
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/project-x" -Interactive $permission = Grant-PnPAzureADAppSitePermission -AppId "ce6bb9a7-c909-4538-b9dd-930724d7259d" -DisplayName "TestApp" -Permissions Write Set-PnPAzureADAppSitePermission -PermissionId $permission.Id -Permissions FullControl
What I explained above is all about a user adding permissions for an application. But what if you want to automate that? It could be necessary in certain scenario’s to do so. You can in fact do this, but you would need another Azure AD Application Registration with the
Sites.FullControl.All app-only permission scope to be able to configure it. This kind of seems to defeat the purpose, but there are cases where it is a good setup. For example: the application that assigns app permissions for other applications may run on a different system where extra care has been taken to avoid security pitfalls.
Having set this all up, the only thing that’s left is to let your application connect to SharePoint. You can do this through Managed Identity (when running an Azure Function, Automation Runbook or App Service), or through a Client Certificate. There are a lot of roads to get connected, using various programming or scripting languages, I won’t go into that here today. But I have blogged about running the CLI for Microsoft 365 on an Azure Function earlier, that is a nice example where RSC would be useful!
Assigning ‘God mode’ to an application on SharePoint should be avoided whenever possible. Fortunately we can restrict permissions to specific SharePoint sites, using Resource Specific Consent. The CLI for Microsoft 365 and PnP.PowerShell offer easy to use tools to get this set-up.
If you have any questions, please drop me a post!
- CLI for Microsoft 365
- CLI for Microsoft 365 - spo site apppermission add
- PnP.PowerShell - Grant-PnPAzureADAppSitePermission
- Microsoft Graph - Create app permissions on sites
- Microsoft Graph - Permission Roles
sharepoint azuread cli-microsoft365 pnp-powershell security
Support me by sharing this
A guide on how to create a .NET application that can access SharePoint and the Microsoft Graph through Azure AD.Read more
Part 3 on how to use the CLI for Microsoft 365 and Azure Functions: How to get notified of updates in guests accessing SharePoint.Read more
Thanks for reading
Thanks for reading my blog, I hope you got what you came for. Blogs of others have been super important during my work. This site is me returning the favor. If you read anything you do not understand because I failed to clarify it enough, please drop me a post using my socials or the contact form.
Microsoft MVP | Microsoft 365 Architect