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
• [X] 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: https://github.com/SharePoint/sp-dev-docs/issues/2472#issuecomment-419208756. 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.

[eoverfield]

@vman for my tenants that did not have any issues with the migration to 1.6, that included aad calls, I did not have to manually add user.read to the new service principal. I am trying to get us clarification if the requirement a few of us are having with the new service principal is actually a bug.

[patmill]

Let me check around and I will follow up on this thread...

OK, so it's a bit strange. This started happening in AAD, and we are following up with that team to figure out if it is expected. We think it doesn't make sense, but... For now, the workaround is to explicitly grand the permission as @Nasicus stated. We hope to get resolution quickly on this one way or another.

If it turns out that in order to use the third party app for any call you need User.Read, then we will explicitly add that when the AAD app is created. It doesn't make sense for you folks to have to do anything in the long term.

In the meantime, we'll update the documentation with the temporary work-around.

[Nasicus]

@eoverfield didn't you say (https://github.com/SharePoint/sp-dev-docs/issues/2472#issuecomment-419228769) that you followed my steps to make it work? Because then you did the same thing,but instead of via the manifest you did it via the App directly (which I think is probably the "wrong" way).

@patmill The reason I figured even out to give this permission is because, after I deployed my app with my "normal permissions", approved them and went to the page where my app is used I had the explicit message that "At least Azure Active Directory "Sign in and Read User Profile" is required".

[baywet]

@Nasicus 's solution worked for us, thanks!

[eoverfield]

@Nasicus I did use your process on two of my tenants and that did fix final issues I ran into. On a few other tenants, I never ran into issues with the recent updates, and I didn't have to follow your steps, the legacy solutions that utilized AAD continued to work. Very interesting.

[s-KaiNet]

Solution by @Nasicus worked for me as well. It also was a combination of two issues - a user is not an admin, and "Windows Azure Active Directory" permission problem

[iainl]

Fixed, thanks all, adding

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

fixed it.

[Nasicus]

@patmill

This post shows the exact message I had, and why I even figured out to requiere this additional permission: https://github.com/SharePoint/sp-dev-docs/issues/2480#issuecomment-419827762

[olemp]

Adding Windows Azure Active Directory scope User.Read fixed the original issue, but I'm still getting a Authorization_RequestDenied response from https://graph.microsoft.com/v1.0/groups using the new MSGraphClient. I've granted the permission scope Group.ReadWrite.All for Microsoft Graph.

[s-KaiNet]

@olemp If you go to azure portal -> azure active directory -> enterprise applications -> switch drop down to Application Type - All -> search for "SharePoint Online Client Extensibility Web Application Principal" -> select it -> permissions -> does permission list contain Group.ReadWrite.All permission, which should be admin consented?

[olemp]

@s-KaiNet My bad. An old access token was cached. Clearing localStorage and sessionStorage solved it for me (not sure which of them the client uses).

[DnsSrinath]

Any idea why "SharePoint Online Client Extensibility web application Principle" not available in my tenant?

Is there a way to enable "SharePoint Online Client Extensibility web application Principle" in a tenant?

I am not able to remove the existing permissions in the API management I am getting "UnKnow Error."

Even from the Powershell command to disable the "SharePoint Online Client Extensibility" I get same "UnKnow Error"

Adding the permission "webApiPermissionRequests" on package bring the permission in the "API manager" but when i try to approve it give "UnKnow Error", I suspect it becuse the API Manger is associated with the "SharePoint Online Client Extensibility web application Principle", becuse the principle is missing, the Permission request could not be updated.

[VesaJuvonen]

Original issue has been fixed and you need to re-approve your permissions. This is either related on the #2472 or related on the missing approvals of the permissions.

@DnsSrinath - your issue seems same as #2522, if that's not the case, please open a new issue and provide needed details. Thx.

[mwiedemeyer]

I just want to add, that I had the same issues and the solution was quiet simple: The "resource" in webApiPermissionRequests element allows only names, not IDs. In our tenant we had 2 different apps in "Enterprise Apps" with the same name and the API Permissions in the new SharePoint Admin Center added the wrong app to the permissions. Solution: Delete the "wrong" app and re-approve the API permissions.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues