Search code examples
sharepointazure-active-directorymicrosoft-graph-apisharepoint-api

Graph API 403 Forbidden - Either scp or roles claim need to be present in the token


My app fails with a 403: Forbidden message when making call to Sharepoint /sites/root. My authorisation flow follows these steps here.

To get a token, I first make a call to https://login.microsoftonline.com/common/adminconsent?client_id=XXX&redirect_uri=XXX&state=12345

This allows me to sign in with an administrator and discover the tenant_id. If accepted, the call returns the query param admin_consent = TRUE and the tenant_id.

I then use this to make a 2nd POST call to https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token with the following body in the request: client_id=XXX&grant_type=client_credentials&client_secret=XXX&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default

NOTE: The scope is set to the Default (https://graph.microsoft.com/.default). I am requesting Sites.ReadWrite.All as an Application permission when I registered the app and that is all.

The response was:

'token_type': 'Bearer',
'expires_in': 3599,
'ext_expires_in': 3599,
'access_token': 'eyJ0...' (deliberately masked)

I then tried to use this in my application with /sites/root endpoint and receive the error 'Either scp or roles claim need to be present in the token'. When I decode the token using https://jwt.io/#encoded-jwt, I cannot see the 'roles' parameter visible.

In the Azure app, I can see that the application was indeed granted Admin access successfully so why doesn't my token return correctly? What am I missing? Surely by user /adminconsent as the first API call I don't need to manually authorise in the Azure portal too?

EDIT: Making a 2nd API call to get a new token after around 50 mins as the first token is close to expiring seems to work, I get the "roles" back in the decoded token. Is there a bug on the graph api causing this issue?

"roles": [
    "Sites.ReadWrite.All"
],

Solution

  • Is there a bug on the graph api causing this issue?

    It is not a bug, all you did is correct, just a simple delay issue, the permission did not take effect when you request the token.