how should we properly configure API scopes and tenant-wide deployment settings to resolve it?

Question

We are developing an SPFx web part that calls Microsoft Graph to retrieve user profile and group membership data. The web part works correctly in the local workbench, but after deployment to the tenant app catalog, it fails with 403 errors when accessing Graph endpoints. API permissions have been granted in Azure AD, and admin consent was approved.

How should we properly configure API scopes and tenant-wide deployment settings to resolve it?

Answer 1

Hi Deborthia Azbill,

Thank you for posting your question in the Microsoft Q&A forum.

Based on what you described, if your SPFx web part is calling Microsoft Graph using the built-in SPFx Graph client (MSGraphClientV3 / msGraphClientFactory), then the behavior you’re seeing can often be explained by how SPFx permissions are actually handled after deployment:

When you deploy an SPFx solution, the Graph permissions used by SPFx are not taken from a custom Entra ID “App registration” that you created. Instead, SPFx permission requests are managed through SharePoint’s tenant-level API permission system. Specifically:

• You must declare the required Graph scopes using webApiPermissionRequests element in config/package-solution.json.
• After deploying the .sppkg to the App Catalog, a Global Administrator must go to SharePoint Admin Center > API management and Approve the pending permission requests.

So, in many cases, granting permissions in an Entra app registration (and consenting that app) does not help an SPFx web part that uses MSGraphClientV3, because the runtime token is issued based on SharePoint’s SPFx principal plus what’s approved in the SharePoint Admin Center API access page.

If you already did all the above and still get 403, could you get back with:

• Which library/client you’re using to call Graph (e.g., MSGraphClientV3, AadHttpClient, PnPjs graph, MSAL, etc.), and
• Which Microsoft doc/tutorial you followed to build the web part?

That will help pinpoint whether the calls are going through SPFx’s built-in auth flow (expected), or through a different auth path that would require different configuration.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".         

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.