Common issues when working with SharePoint Framework API permissions

SharePoint Framework API permissions significantly simplify connecting to APIs securing with Azure AD. There are however a few things that you need to watch out for or you will be stuck.

Easily connect to APIs secured with Azure AD

Authentication is hard but security is necessary to ensure that your organization’s data stays safe. At the same time, it makes you spend more time than necessary trying to connect to your organization’s APIs. You have to decide which OAuth flow you need, what kind of Azure AD application to create, how to securely store the access token, not to mention to ensure that the whole setup will work with multiple web parts on the same page requesting access tokens simultaneously.

For building SharePoint Framework solutions, Microsoft simplifies working with APIs secured with Azure AD through the AadHttpClient. The AadHttpClient abstracts away obtaining and managing OAuth access tokens allowing you to focus on building your solution. It just works.

Common pitfalls when working connecting to APIs secured with Azure AD in SharePoint Framework solutions

The AadHttpClient is invaluable and using it saves you a lot of time. Still, there are a number of things that you should be aware of so you do not to get stuck when using it in your solutions. Here are a few of them.

Unknown Azure AD application

After loading the page, one of the web parts or extensions shows an error similar to the following:

This error occurs when your API is secured with an Azure AD application registered in a different Azure AD than the one used by your Office 365 tenant. This application hasn’t been consented by the administrator to be used in your organization.

To fix this issue you need to complete the consent flow. You can do this in the web browser by navigating to the API URL, signing in with your Office 365 account and consenting to the usage of the API in your organization. You can confirm that the administrator has consented to using the application  in the Azure Portal by navigating to Azure AD Enterprise applications.

Insufficient permissions to view the page

When trying to consent the usage of an API secured with Azure AD in your organization, you get the following error:

This is most likely caused by the fact that an Azure AD application with the same App ID URI is already registered in your organization. You should be able to confirm this by navigating in the Azure Portal to Azure AD Enterprise applications.

To fix this issue, either change the App ID URI of the Azure AD application used to secure your API, or delete the old application from the Azure AD used by your Office 365 tenant.

Invalid Issuer URL

When trying to consent to the usage of the API in your tenant, you get the following error:

When securing the API using Azure AD, most likely you used the Express mode to create the Azure AD application. As a result, Azure AD configured the Issuer URL of this application to the Azure AD where the application is registered and which is different than the Azure AD used by your Office 365 tenant. As a result, Azure AD doesn’t allow the application to be used by accounts from other Azure ADs.

To fix this issue, in the API authentication configuration, change the Azure AD configuration mode to Advanced and clear the Issuer URL.

Single-tenant Azure AD application

When trying to consent to the usage of the API in your tenant, you get the following error:

The IDs will, of course, be different and specific to your Azure AD and application. This error is being caused by you trying to use the API in the context of your Office 365 tenant, while the Azure AD application used to secure the API is registered as a single-tenant application in a different Azure AD than the one used by Office 365.

To fix this issue, change the application to be multi-tenanted in its registration settings.

Service principal not found

When trying to grant API permission or approve API permission request, you get the following error:

or this one:

You’re trying to grant API permissions to an Azure AD application that is registered in a different Azure AD than the one used by your Office 365 tenant, while the administrator hasn’t consented to using the application yet.

To fix this issue, you need to complete the consent flow. You can do this in the web browser by navigating to the API URL, signing in with your Office 365 account and consenting to the usage of the API in your organization.

Scope user_impersonation not found

When trying to grant API permissions, you get the following error:

This error is often caused when trying to grant permissions for an Azure AD application registered in a different Azure AD and which has been deleted. Unfortunately, deleting the Azure AD application in its original AD doesn’t remove the existing references, so while the Azure AD used by your Office 365 tenant would still be showing the Azure AD application in its list of applications, you will not be able to grant it any permissions.

To fix this issue, create a new Azure AD application and use it to secure your API.

API permissions not granted

After loading the page, one of the web parts or extensions shows an error similar to the following:

This common error is caused by the API permissions required by the component not being granted in the API management page. You should double check which permissions and to which APIs your component requires, and if they are granted in the API management.

Insufficient CORS configuration

After loading the page, one of your components shows an error similar to the following:

This error is caused by insufficient CORS configuration on the API that you’re calling. Because your component is communicating with the API client-side, the API must specify the domain of your SharePoint tenant in its CORS configuration, or the request will be blocked by the web browser with the aforementioned error.

To fix the issue, navigate to the CORS settings of your Azure Function and add your SharePoint Online domain to the list of approved origins.

Summary

SharePoint Framework API permissions significantly simplify connecting to APIs securing with Azure AD. To successfully secure an API using Azure AD and communicate with it from a SharePoint Framework solution, you need to be aware of a number of settings or you will be stuck trying to decipher the cryptic error messages.

Over to you

New vulnerabilities are discovered every so it’s it’s important to keep a tight grip on what happening with your API permissions.  It’s not enough to audit your SharePoint applications and environment only once. Regularly analyzing your applications will help you discover any threats before they become an issue. Rencore simplifies it, allowing you to focus on helping your organization to stay secure.

Try our free risk assessment today and be on the safe side.

Free Risk Assessment

This blog post was originally posted on Waldek’s blog

About the author

Waldek is a Microsoft Office Development MVP and Head of Product at Rencore. He reinforces our product development adding loads of business experience from working as a SharePoint consultant for more than 10 years. Waldek is passionate about what he does and shares his enthusiasm through his blog and as a regular speaker at conferences and community events all over Europe. Recently, Waldek joined the SharePoint Patterns and Practices (PnP) Core Team to help developers make better use of the SharePoint and Office 365 platforms.