When securing your API access with permissions there is the option to let the user give consent to the required permissions or to grant it admin based and organization wide. While the latter one is simple, necessary for sensitive permissions and can be revoked easily from the Azure AD portal, the former one should be good practice, especially in security sensitive or ZeroTrust environments. But especially during development there might be the need to test giving consent several times. So what about revoking user consented permissions? Here I show you a simple way to handle this.
Assume you have an application that requires user consent for your application permissions, for instance when calling Microsoft Graph API. Every user might receive something like this:
Especially in ZeroTrust environments it is good practice to implement it like this and not “shortcut” such handling by giving Admin consent and leaving the user unclear about permissions used behind the scenes. But what happens when the user clicks on “Accept”, where can the result be found? Somewhere in the app registration, maybe?
No, unfortunately not. As a simple explanation about the difference about an app registration and an Enterprise application maybe think about a “multi-tenant” app. The app registration always resides in the tenant where it was created. If it’s used in another tenant, only an Enterprise application (not đź’Ż true, see below) is created. For instance think about the very well known “SharePoint Online Client Extensibility” used by SPFx, which you will only find under Enterprise applications in your tenant, as it’s from Microsoft originally. User consent now is tenant-specific, as is the user itself. So looking into the Enterprise application we might discover successfully:
If you have problems to find your app under “Enterprise Applications” simply remove “Enterprise Application” from the search tags. In fact, we are talking about a service principal only here. And that understanding helps in the next step.
So what about deleting those given consent? You shouldn’t look further (at the time of writing this) you won’t find anything here in the portal. But let’s try with Microsoft Graph and there for “simple bug fixing purposes” in the comfortable Graph Explorer. But first we need an ID of this object: So let’s take:
Using that given objectID in a simple Microsoft Graph request like
https://graph.microsoft.com/v1.0/servicePrincipals/{objectID}/oauth2PermissionGrantsYou will receive all granted user consents for that app registration … sorry… service principal to be precise.
Clearly identifiable is the scope, but also the USER ID I marked here for instance. To delete this now we need to pick the “id” here and go to the “source” of the oauth2PermissionGrant. What’s shown above is only the relationship on the service principal. So take another Microsoft Graph endpoint to get to the source:
GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants/{id}The result looks similar than above:
But here now we can simply turn the request into a DELETE
and as a result the user consent is gone
How simple is that? I hope it helps you during your development activities. Especially when trying to get your applications as secure as possible.
|
Markus is a SharePoint architect and technical consultant with focus on latest technology stack in Microsoft 365 Development. He loves SharePoint Framework but also has a passion for Microsoft Graph and Teams Development. He works for Avanade as an expert for Microsoft 365 Dev and is based in Munich. In 2021 he received his first Microsoft MVP award in M365 Development for his continuous community contributions. Although if partially inspired by his daily work opinions are always personal. |
Markus Moeller's SharePoint and M365Dev Blog 
One thought on “Remove user consent from an Azure AD Enterprise application / service principal with Microsoft Graph”