CODEWITHSUNDEEP
azure-active-directorymicrosoft-graph-api
user9465677
user9465677

Reputation: 427

Azure AD / Microsoft Graph Access Level Upgrade and Downgrade

Is there a way to upgrade and downgrade the Azure AD / Microsoft Graph access level?

For example, can a user signup with a web app only to login and later upgrade access to One Drive or downgrade back to login? I was looking for a way to unauthorize the user access and then reauthorize with the different set of permissions but couldn't find a way to unauthorize.

Upvotes: 1

Views: 196

Answers (1)

juunas
juunas

Reputation: 58763

You can get incremental consent if you use the V2 endpoint: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-appmodel-v2-overview. There you can specify which scopes you want to require when redirecting the user to login.

So you can require basic ones at the start, and then if they want to enable additional features/you release an update which requires additional permissions, you can add those quite easily.

As for the other direction, no. Once a user has given consent for some permissions, the only way to undo the consent would be to delete the oauth2PermissionGrant object mapping the user to the application's service principal. In case of an application permission, an appRoleAssignment would need to be deleted from the service principal.

So it's possible, but you will have to call Microsoft Graph API yourself.

You can get all permission grants via: https://graph.microsoft.com/beta/oauth2PermissionGrants and it returns grant objects like this:

{
    "clientId": "e846195b-9b20-4001-ad84-5ab5de5531e6",
    "consentType": "AllPrincipals",
    "expiryTime": "2018-05-04T09:39:32.9697945Z",
    "id": "WxlG6CCbAUCthFq13lUx5s7PF6398j5LkfWqCoLpQBI",
    "principalId": null,
    "resourceId": "ad17cfce-f2fd-4b3e-91f5-aa0a82e94012",
    "scope": "User.Read Directory.AccessAsUser.All",
    "startTime": "0001-01-01T00:00:00Z"
}

This one is actually the result of admin consent (consentType = AllPrincipals and principalId = null). For regular user consent, principalId will be the id of the user. clientId is the id of the service principal who was granted access, and resourceId is the target service principal.

You can also filter the results to a specific user for example: https://graph.microsoft.com/beta/oauth2PermissionGrants?$filter=principalId eq '73c38a25-23eb-44eb-bf63-4aa987b2ef19'

You can then update the grant to change the approved scopes by running a PATCH to https://graph.microsoft.com/beta/oauth2PermissionGrants/WxlG6CCbAUCthFq13lUx5s7PF6398j5LkfWqCoLpQBI with a body like:

{
    "scope": "User.Read"
}

You can delete the grant entirely by running a DELETE on the same URL.

Upvotes: 5

Related Questions