Managing SharePoint Framework API Permissions with PowerShell

Last updated on April 4, 2025

Recently, Microsoft announced that they are transitioning from using the SharePoint Online Client Extensibility Web Application Principal to the SharePoint Online Web Client Extensibility application principal for SharePoint Framework (SPFx) permission management. During this transition, the permissions that exist on the previously used application principal are supposed to be copied automatically to the new one to avoid service disruption. However, for one of my customers, this automatic migration of permissions only worked for Microsoft Graph permissions, not for the permissions granted to custom APIs running on their Azure subscription, protected by Entra ID authentication.

The problem

One morning, the SharePoint Framework web parts that relied on these custom APIs started failing, resulting in two additional page refreshes whenever someone navigated to a page where one of these web parts was located as the web part desperately attempted to authenticate to the API. The permissions had disappeared from the SharePoint Online Admin Center’s API Access page, and the browser developer tools’ console displayed the following error.

Fixing the issue

After the transition, permissions granted via the SharePoint Online Admin Center’s API Access page are meant to go directly to the new SharePoint Online Web Client Extensibility application principal, similar to how the process has worked before with the previously used application principal. However, re-granting the permissions this way had no effect, even though the permissions did show up on the API Access page again.

Before this change, one could always fall back to granting the permissions via the SharePoint Online Client Extensibility Web Application Principal Entra ID application registration if there were any issues with the API Access page. However, the new SharePoint Online Web Client Extensibility does not have an app reg on Entra ID. The only way to manage those permissions is via PowerShell.

PowerShell as fallback

Luckily, Microsoft provided a script for granting permissions as a part of their announcement blog post. However, I rarely have global admin permissions in customer tenants, so I am unable to run the script myself, and asking my not-always-so-tech-savvy customers to first manually install the required Microsoft Graph PowerShell module and then provide the app ID and scope parameters when running the scripts didn’t seem like good customer service. Hence, I created my version of the script with the following changes:

1. The script doesn’t accept any parameters. Instead, the variables are already specified in the script (I specify them before sending the script to the customer).
2. The script checks if the minimum required PowerShell modules are installed and, if not, automatically installs them.
3. The same script can grant multiple permissions for the same API (you often need to grant multiple scopes for Microsoft Graph) and for multiple instances of the API (in my case, test and production versions of the custom API).
4. The script prints out more descriptive output messages to the console while silencing the pointless disconnect message.

These changes mean that the customer can simply run the script I sent them as is, with no other steps required, and can clearly see what changed.

While testing the script before sending it to my customer, I figured it would also be nice to be able to read and delete the already existing permissions. Thus, I wrote scripts for performing those tasks as well. Being an active member of this awesome Microsoft 365 Developer community, I figured I’d share the scripts with you! So, here you go. Sharing is caring!

The scripts

All of the scripts have similar logic and requirements. Before running the script, you need to specify the client ID of the API and the scopes you wish to add/remove(unless you are simply checking existing grants). When running the script, consent to the installation of the required modules if you’ve not previously installed them. Finally, check the console output to see if the result matches your expectations.

Granting permissions

Reading existing permissions

Deleting permissions

When the last permission scope is deleted for an API, the remaining empty API object is deleted.

Afterword

I hope the permission transition goes smoothly for your tenant. However, if you need to manage SharePoint Framework API permissions programmatically, I hope you’ll find these scripts useful. If you’d like to get notified whenever I publish new content, make sure to follow me on LinkedIn and/or subscribe to blog notifications via the sidebar (bottom for mobile).

Happy coding!

Laura