Recently I was working with a Microsoft Graph partner and ran into an interesting scenario around calling Microsoft Graph endpoints from SharePoint Framework (SPFx) web parts using delegated permissions that I want to share.
Scenario
The partner was building a SPFx web part that was making calls to Microsoft Graph using the MSGraphClient. While making calls to specific endpoints on Microsoft Graph they were receiving a 403 Forbidden error response. We checked the permissions granted and consented and everything appeared in order.
Digging deeper into the MSGraphClient implementation I found that it uses an ImplicitMSALAuthenticationProvider for acquiring the authentication token. Implicit authentication is important to keep in mind in this scenario.
Use the MSGraphClient to connect to Microsoft Graph https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-msgraph
Microsoft Graph JavaScript Client Library – Authenticate for the Microsoft Graph service https://www.npmjs.com/package/@microsoft/microsoft-graph-client#2-authenticate-for-the-microsoft-graph-service
I used https://jwt.ms (provided by the Microsoft Identity Platform team) to decode a sample token from the partner and then again to decode an access token I had acquired in my lab environment. I noticed that the partner’s access token did not have the “wids” claim while my lab access token did have that claim.
Thanks to a contact in O365 software engineering who was able to confirm that the “wids” claim contains the tenant-wide roles assigned to the user. As noted in the documentation implicit authentication flows may not return the “wids” claim due to token length concerns.
Microsoft identity platform access tokens – payload claims
https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#payload-claims
Looking at one of the Microsoft Graph endpoints that the partner was calling (getOffice365GroupsActivityDetail) we found the below note explaining that when using delegated permissions (which the partner was using) the user context must also be assigned to an appropriate Azure AD limited administrator role.
Note: For delegated permissions to allow apps to read service usage reports on behalf of a user, the tenant administrator must have assigned the user the appropriate Azure AD limited administrator role. For more details, see Authorization for APIs to read Microsoft 365 usage reports.
https://docs.microsoft.com/en-us/graph/api/reportroot-getoffice365groupsactivitydetail?view=graph-rest-1.0#permissions
Putting the pieces together, the query was failing an authentication check because the access token passed to the endpoint did not have the necessary claim containing the assigned Azure AD roles. Hence the “invalid permissions” response.
Conclusion
This is an edge case scenario that took some collaboration with various groups within Microsoft to track down. Many thanks to my peers who helped with identifying additional information as we investigated. I submitted a pull request to the SPFx documentation that has been merged to call out this behavior (see Known Issues on this link). So far that I can tell only the Microsoft 365 usage reports endpoints on Microsoft Graph may have an Azure AD role requirement.
Authorization for APIs to read Microsoft 365 usage reports
https://docs.microsoft.com/en-us/graph/reportroot-authorization
Hopefully this post helps others who may run into this scenario. If you find additional similar scenarios feel free to let me know in the comments.
-Frog Out
The Frog Pond of Technology 
Hi Brian,
Thank you for the nice articulated blog. Even we were facing an Authorization error while we try to add/ remove members from the O365 Private Group using MSGrpahClient in SharePoint Framework webpart.
{
“error”: {
“code”: “Authorization_RequestDenied”,
“message”: “Insufficient privileges to complete the operation.”,
“innerError”: {
“date”: “2020-09-10T08:14:47”,
“request-id”: “1562b1e8-aa40-4b46-96a9-def08c10df85”
}
}
}
Is it something related with “wid”, Even though this api call works when its executed by a user who is owner of that private group. We have tried by giving Group.ReadWrite.All or GroupMember.ReadWrite.All or Directory.ReadWrite.All along with User.Read.All.
Thanks
LikeLike
I’m not aware of that endpoint (add members to group) requiring an Azure AD role, so unlikely that is the cause. Generally that exception is thrown when the permissions are not correctly assigned, calling against the wrong tenant, or other misconfiguration. Take a look at the documentation for SPFx calling Microsoft Graph: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aad-tutorial.
LikeLike
Hi sir, facing same issue with power bi endpoints as admin related APIs are giving 401 due to missing wids,
Did you find any solution for that like forcefully merge wids in token ?
Thanks
LikeLike
Unfortunately I’m not aware if it is possible (or supported) to modify the token that is returned. My assumption is that no it is not otherwise that would compromise the integrity of the token.
LikeLike
Hello Sir , Can you please provide the steps to add the user as Azure AD limited administrator .
LikeLike
I’m not familiar with the limited administrator role? Does this relate to Azure resources, Azure AD, or something else?
LikeLike
[…] Calling Microsoft Graph with Delegated Implicit Authentication(briantjackett.com) […]
LikeLike
Hi Brian !
Thanks for the great investigation on this case.
2023 and I am facing the exact same problem. I had a look at your github discussion on this case and I am not sure to fully understand the conclusion.
Is it just not possible to call getOffice365GroupsActivityDetail from SPFX because the wids won’t be filled in the token ( what I see right now in my case ) or has a fix been made ?
Thanks a lot for your help !
LikeLike
Julien, unfortunately I have not looked into this scenario in a few years. To my knowledge this has not been resolved. Since this is a dependency on the underlying authentication library and requests that it makes, would likely need to be a change made there rather than Microsoft Graph or SPFx.
LikeLike