Calling Microsoft Graph Endpoint with Delegated Implicit Authentication Does Not Include Azure AD Roles

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.


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.

403 Forbidden error screenshot.

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

Microsoft Graph JavaScript Client Library – Authenticate for the Microsoft Graph service

I used (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.

Screenshot of documentation on "wids" claim.  Highlight that this claim might not be returned for implicit authentication flow.

Microsoft identity platform 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.

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.


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

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

9 thoughts on “Calling Microsoft Graph Endpoint with Delegated Implicit Authentication Does Not Include Azure AD Roles

  1. 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.


  2. 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 ?



    • 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.


  3. 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 !


    • 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s