Why does SPFx fail to acquire token for Azure AD–secured API after deployment?

Hi @Von Mastein Jr

Based on your description, this issue is most likely related to a missing or mismatched tenant‑level permission grant for your custom Azure AD-secured API after deploying the SPFx solution. 

This behavior is common because the local workbench (gulp serve) uses a more permissive authentication flow that does not fully enforce SharePoint Online’s token service checks. In that mode, Azure AD can often issue tokens directly based on the developer’s sign-in context. 

After you package and deploy the .sppkg to the tenant app catalog, however, the web part runs under the actual SharePoint Online app principal. At that point, explicit permission declarations and tenant admin approval are mandatory. If those are missing, AadHttpClient cannot acquire an access token on behalf of the user, which results in errors such as “Failed to retrieve access token” or the underlying AADSTS500011. 

Typically, AADSTS500011 indicates that Azure AD cannot find the resource (audience) you are requesting a token for in the current tenant. In SPFx and custom API integrations, this is typically triggered by one of the following: 

Passing an incorrect value to aadHttpClientFactory.getClient(...) (for example, using the plain client ID GUID instead of the Application ID URI). 

The API app registration’s Application ID URI (“Expose an API”) is misconfigured or not referenced correctly. 

The API permission request was never approved in SharePoint, or the resource name in package-solution.json does not exactly match the Azure AD app registration display name. 

To troubleshoot it, you could try to follow these steps: 

In your API’s Azure AD app registration

Go to Expose an API and ensure an Application ID URI is defined  (typically api://<client-id-of-this-app> or a custom URI such as https://yourtenant.onmicrosoft.com/yourapi). 

Expose the required scopes  (for example: access_as_user, user_impersonation, etc.). 

Ensure user or admin consent is granted for those scopes if required. 

Update package-solution.json

Add or correct the webApiPermissionRequests array under the solution node: 

"webApiPermissionRequests": [   
{   
"resource": "<Exact Display Name of your API app registration in Azure AD>",   
"scope": "<Scope name you exposed, e.g. user_impersonation or access_as_user>"   
}   
]   

You can refer via this link.

Re-package and re-deploy 

gulp bundle --ship   
gulp package-solution --ship   

Upload the new .sppkg file to the tenant app catalog (and deploy it if you are using tenant-wide deployment). 

Approve the permission in SharePoint Admin Center 

Go to SharePoint Admin Center > Advanced > API access 

You should see a pending request for your API app name and scope 

Select Approve (permission propagation may take a few minutes) 

In your SPFx code – double-check the client call 

const client: AadHttpClient =   
await this.context.aadHttpClientFactory.getClient(   
"api://<client-id-of-your-API-app>" // MUST be the Application ID URI, not just the GUID   
); 
const response = await client.get(   
"https://your-api-endpoint/...",   
AadHttpClient.configurations.v1   
);

Note: Do not use the plain client ID (GUID only) or the API endpoint URL as the resource value. 

Then you can refresh and test again to see if the issue still persists.

I hope this helps. 

Please understand that our initial reply may not always immediately resolve the issue. However, with your help and more detailed information, we can work together to find a solution. 

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.