AADSTS500011 — Error in AAD Authenticated Azure API call from SharePoint Framework
I had followed the official MS documentation in order to invoke an enterprise api from an SPFx App (using the pnp AdalClient instead of AadHttpClient)
The steps are briefly described below.
- Create an Azure Web App.
- Enable Authentication on the Web App. (This step will internally create an Enterprise App Registration in Azure AD exposes an ‘user_impersonation’ scope on the Enterprise App Registration).
3. Provide Admin Consent for the Enterprise App in AAD (AD Admin access required).
4. Deploy the api code to the Web App.
5. Add the SharePoint tenant as a CORS Origin in the Web App and Check the Request Credentials box.
6. Create the SPFx Solution.
7. Add the custom webapi Permission Request to the package-solution file.
9. Add the auth client in SPFx code .The recommended approach is to make use of pnp msalclient with a separate client id for the particular SPFx app . (In my case I used pnp adalclient since I wanted to create the api permission request on the SharePoint Online App Principal ).
10. Package and Deploy the SPFx app to the tenant.
11. Approve the api permission request in SharePoint Admin Center.
(This step will internally add permissions for the “SharePoint Online Client Extensibility Web Application Principal” in AAD on the new api’s exposed(user_impersonation) scope).
12. Add the App to the SharePoint Site.
13. Add the Web Part to a SharePoint page and invoke api.
At this stage the process is completed and we should be able to call the API as per the documentation.
However, I faced the below error.
{“errorCode”:”invalid_resource”,”errorMessage”:”AADSTS500011: The resource principal named https://spfxapiauth.azurewebsites.net was not found in the tenant named 86182542–823c-421c-8e5d-09bbd72ce34f. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.\r\nTrace ID: 3d38b5b6-f9eb-4607–870f-48cc2d800501\r\nCorrelation ID: 875e0f96-b0f0–4d24–93ff-b810b349cbc6\r\nTimestamp: 2021–06–21 09:47:38Z”,”name”:”ServerError”}
Solution
- Change the auto generated Application ID URI for the AD App under App Registrations in AAD to the api URL.
After this is completed , the application will now be recognized by AAD and a token will be generated by the authorize end point . However the API still didn’t accept the token and the error on the page changes to a 401 .
2. Add the APP URL in the “Allowed token Audience” section in the web app’s Authentication Settings.
Once this is done, the 401 error would go away and the api will start accepting the bearer token .
Fin!
Below are some observations from my troubleshooting
- Do not use Session variables in the API code. Even through the Session variables might work while directly testing the api , there is no session established when the API is called cross domain in a SharePoint page . The Authn/Authz always happens through the Bearer token on every request independently .
- The above approach did not solve the 401 Error when the authentication was enabled via the new Auth settings page (screenshot below) of Azure Web App. My workaround was to first enable authentication using classic auth settings page and then upgrade to the new auth experience. (Need further troubleshooting to get to the bottom of this).
