Share via

App Registrations Permissions Revoke User Consent

Gabriel Auger 10 Reputation points
2023-10-17T16:33:40.9+00:00

Hello,

When I create an application through Azure Portal / app registrations I can add a permission for a user to consent to. Then user sign-in and consents to the permission.

Later on I can remove that permission through app registrations. New user won't be able to consent to that permission. However previous user is still able to use that permission.

The only way to remove that permission is to go to Azure Portal / Enterprise applications / my app / permissions / user consent. From there a PowerShell Script is provided to revoke the permissions for my app.

I can't run that script as a configuration owner, I need to be a Cloud Application Administrator for that.

In order to do that I need to reach to my admin department. Meanwhile the permission has been revoked but previous user can still use it.

From my understanding it is a permission design flow. If I am allowed to enable permission to a user, I should be able to remove that permission too and make it effective to anybody using my app. The configuration owner of an application should have enough privileges to be able to revoke user consent for its own app.

Why Microsoft decided to leave a user access to a permission when configuration owner explicitly removed it?

Why configuration owner has enough privileges to add multiple permissions but then doesn't have enough privileges to revoke previous user permissions when permissions have been removed?

Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
11,449 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,408 questions
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vasil Michev 100.2K Reputation points MVP
    2023-10-18T07:40:04.1966667+00:00

    That's not how it works though. While you can certainly add permissions on the application object, said permissions need to be consented to either by the user, or an admin. When consenting to permissions, they are stamped on the corresponding service principal object, not the application object.

    So you're effectively "describing" what permissions the app should get (via the application object), but not making the actual decision to grant them (on the matching service principal). And it's the whole point behind the consent process.

    You can always check the set of scopes within the user's access token and if certain permission is missing (or is "extra"), you can block/grant access on the app layer itself. But revoking permissions on the service principal object is a directory-level operation, which you can only perform if the app has been granted the necessary permissions (DelegatedPermissionGrant.ReadWrite.All).