SPFx The user or administrator has not consented to use the application with ID '<guid>' named 'SharePoint Online Client Extensibility Web Application Principal'

[pbjorklund]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

AadHttpClient should work according to previous (1.5 plus version)

Observed Behavior

Deployed and trusted webApiPermissions requested by app onto a production environment with no targeted release.

Ran o365$ spo serviceprincipal set -e true

SharePoint Online Client Extensibility Web Application Principal exists in https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps with matching from above. Redeployed solutions and re-trusted API.

Recieve console message below from SPFx solution

Uncaught (in promise) Error: AADSTS65001: The user or administrator has not consented to use the application with ID '1565f76c-d88e-4586-9d23-9ef27af612c3' named 'SharePoint Online Client Extensibility Web Application Principal'. Send an interactive authorization request for this user and resource.
Trace ID: 0b113a29-86da-4039-96c6-01880a440100
Correlation ID: 8fac6554-c3a2-40d4-9cfd-ba99f5a89408
Timestamp: 2018-09-06 08:06:29Z
    at Array.<anonymous> (sp-pages-assembly_en-us_2fd01d9d9722e6b700aca2046e1c70ae.js:988)
    at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-27.007/1.sp-http-adal_58855c41adb591deebd1.js:3:7561)
    at AuthenticationContext.handleWindowCallback (VM96 adal.min.js:2)
    at parseTokenFromUrl (spfxsinglesignon.aspx:20)
    at onload (VM160 spfxsinglesignon.aspx:31)

Response from: /_forms/spfxsinglesignon.aspx#error=interaction_required&error_description=AADSTS65001%3a+The+user+or+administrator+has+not+consented+to+use+the+application+with+ID

[pbjorklund]

Edit: Scratch that, still doesn't work.

[pbjorklund]

The APIs trusted from https://tenant-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement ends up correctly in the "SharePoint Online Client Extensibility Web Application Principal" in AAD under Permissions as it should.

I guess that the "SharePoint Online Client Extensibility Web Application Principal" is supposed to handle SPFx signins and therefor needs permissions to Sign in users from AAD granted globally and that this one lacks the grant that was previously globally deployed from Microsoft. Perhaps it was cleared when 1.6 was deployed and the grants were cleared?

Can't debug since I don't have global admin (but have Application Admin and Cloud Application Admin) roles.

Edit:

So if I need to retrust this service principal - what permissions should it be granted? I need to send the list to a global admin at the customer who don't really have time to figure it out by trial and error :) (Edit delegated works, no global admin required)

End of wild speculations

Edit 2:

Ok. So when adding and granting the below permissions to the SharePoint Online Client Extensibility Web Application Principal app registration it removed the API permission from the new SP admin center but added the AD permissions.

So after a redeploy of the sspkg and a new trust we get:

And after that everything seems to be smooth sailing.

[eoverfield]

I believe this is the expected output based on the update to spfx 1.6. All granted permissions to AAD in SPO had to be re-granted per 1.6 release notes: https://github.com/SharePoint/sp-dev-docs/wiki/SharePoint-Framework-v1.6-release-notes

[Nasicus]

@eoverfield agreed.
The bug / strange thing here is for me that we manually need to give the Windows Azure Active Directory permission Sing and read user profile to the automatically created application SharePoint Online Client Extensibility Web Application Principal.
This is (as far as I could see) not documented anywhere.

I would be happy if one of the SP guys (@VesaJuvonen @lucaband @mcmynn83 @patmill ) could explain to me if this is indeed the normal process. Of if the application was for some reason created without this permission. And if it is expected it should definitely be added to the documentation.

---

Just FYI this is my current "update documentation" (from SPFX 1.4.1 to my new SPFx 1.6 app):

  - Go to the "API Management"-section in the SharePoint Preview Admin Center (https://TENANT-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement)
  - Ensure that no permissions are there anymore 
  - Head over to the App Registrations Page in the Azure Portal.
  - Click "View all applications"
  - Click "SharePoint Online Client Extensibility Web Application Principal"
  - Choose "Settings" > "Required Permissions"
  - Click "Add"
    - "Select an API" and choose "Windows Azure Active Directory", press "Select"
    - "Select Permissions" and choose "Sign in and read user profile", press "Select"
  - Click "Done"
  - Click "Grant permissions" and "Yes"
  - Update the app package in the app catalog
  - Head back to the "API Managment"-section:
    - Ensure that "Windows Azure Active Directory" is already listed in the approved permissions (this permission should be here because of the previously executed steps).
    - Approve all permission requests one by one. Once this is done, reload the page to ensure that all permissions are actually approved as the SharePoint UI doesn't always behave as expected.
  - Wait a couple of minutes
  - Log out of SharePoint, close all browser windows and log in again
  - Access your intranet and everything should be fine

[eoverfield]

@Nasicus It looks as though there are found issues and I am sure Microsoft will solve this. @VesaJuvonen provided more guidance here: #2472 (comment). Once this has been fixed, I am sure we will get instructions if anything needs to be done.

[Nasicus]

@eoverfield I know they did, I read the other issue :) I just think these 2 errors/problems are not directly related.
I migrated/installed quite a few tenants today.
My approach was always the same (see my post above). This worked for almost all tenants, expect where I had this exception (which they are indeed investigating right now). But having to give permission to the SPFx principal app seems like a separate issue to me, that's why I wanted to show it to them :)

[patmill]

I think this is the answer you are looking for. With the move to GA, the new service principal that we create has 0 permissions. You will need to explicitly ask for the permissions you need. We did this so that over time, if the 1st party permissions change (say we add something, then remove it), you're code will continue to work as expected.

Does that answer your question?

[vman]

This worked for me by adding the AAD User.Read permission in the package-solution.json and then re-uploading the solution to the App Catalog and then granting the permissions again from the API Management page:

"webApiPermissionRequests": [
      {
        "resource": "Windows Azure Active Directory",
        "scope": "User.Read"
      }
    ]

(I am calling a custom Azure Function on behalf of the current user)

Edit: Removed solution specific permissions.

[qz2017]

For now, you have to add User.Read to enable sign-in. By default, there is no permission granted for you.

https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes#PermissionScopeDetails

[Nasicus]

@patmill

If we really have to ALWAYS add the permission

      {
        "resource": "Windows Azure Active Directory",
        "scope": "User.Read"
      }

to the webApiPermissionRequests, then this really has to be added to the documentation:
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient

[vman]

Can I suggest to go forward a step and add the permission to the package-solution.json through the SPFx generator itself? If it is going to be needed in all cases, makes sense to have it in the default scaffolding.