Microsoft Graph API token's scope is different from the ones set in the Azure portal

4
votes

By using jwt.io I managed to determine the token my app acquires for Microsoft Graph API only contains the scopes for Directory.Read.All and User.Read:

enter image description here

And this is different from the permissions I set in the Azure portal which contains a lot more scopes, such as User.ReadBasic.All:

enter image description here

Is there anyway to fix this?

1
c#asp.netazureoffice365microsoft-graph-api
Check out the service principals grants via Graph Explorer. Find your app's principal under /servicePrincipals, then check /servicePrincipals/object-id/oauth2PermissionGrants. This will tell you which delegated permissions have been authorized for the app. – juunas
@juunas can you put up the full request link for the graph explorer please, sorry I'm still new to microsoft graph – yfan183
Wow, the Graph Explorer has been updated just now.. So the new address is actually graphexplorer.azurewebsites.net. You will have to sign in there, and then type something like this into the text box: https://graph.windows.net/myazuread.onmicrosoft.com/servicePrincipals, and then hit Go. And by the way, this explorer is for Azure AD Graph API, not Microsoft Graph API. Different APIs. But the point here is to check permission grants for your app in Azure AD. – juunas
@juunas there wasn't a property called oauth2PermissionGrants but only oauth2Permissions however it doesn't display any scope in the json, only admin and user consent description displaying a very vague discription of "adminConsentDescription": "Allow the application to access AppName on behalf of the signed-in user." – yfan183
That's the wrong thing :) Those are the permissions provided by your app, not the ones it is using. Once you find your principal, change the URL in the text box to e.g. https://graph.windows.net/myazuread.onmicrosoft.com/servicePrincipals/service-principal-object-id/oauth2PermissionGrants. Just grab the objectId of the service principal and replace service-principal-object-id with it. These grants are a navigation property and are not visible there on the principal itself. – juunas

1 Answers

6
votes

I see this commonly when you go back to your app and add additional permissions AFTER a user has already logged in and consented to your app. That user continues to get the "old" permissions, but new users would get the new set.

If my guess is right, then you probably originally registered the app with just Directory.Read.All and User.Read. You logged in with your user account. You then went and added additional permissions and tried again. Does that sound right?

The problem is that Azure's v1 endpoints don't dynamically update the scopes for users that have already consented. You need to force a "re-consent" experience for these users. Add a prompt=consent parameter to your authorize URL. That should cause the user to see the consent screen again with the updated list of permissions.