App admin consent workflow – What is looks like in action
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow
By default, in Azure Active Directory (Azure AD), users can consent to third party applications to access their organizational information – information pertaining to them from the organizational directory.
Different permissions allow the application different levels of access to your users’ and your organization’s data. Some application have access to the user’s mailbox and Teams conversations.
Allowing users to grant third party applications access to corporate data in this way is risky and increases an organization’s surface area for phishing attacks and data breaches.
Further to this, if the user granting consent is a Global Administrator, an Application Administrator, or a Cloud Application Administrator (and MattChatt doesn’t condone using an admin account as your day-to-day account for accessing emails and third party apps), a “rogue” third party application could request access to ALL company data or tenant-wide access
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent
Warning
Granting tenant-wide admin consent to an application will grant the app and the app’s publisher access to your organization’s data.
Microsoft recommends disabling future user consent operations to help reduce your surface area and mitigate this risk.
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent
With these risks in mind, it is recommended (by Microsoft themselves) to disable user consent operations.
See how to disable user app consent here
After disabling user app consent however, users will be blocked from accessing legitimate third party apps that require permission to access organization data. The user gets an unauthorized error message suggesting they contact an administrator.
The admin consent workflow (preview) feature is a way for users to send a request for a delegated administrator to approve the request by reviewing the permissions and deciding whether or not to approve the request. The approval is sent to the admin in an email. (So the admin account needs to have an Exchange mailbox)
See how to enable the admin consent workflow (preview) feature here
Here is what the admin consent requests look like to when received by an administrator (global administrator, cloud application administrator, or application administrator) selected as a reviewer.
Note there is an expiry to the request, so if the admin ignores it, the request will expire after the stipulated date.
The admin then signs into the request (Azure AD Enterprise Applications Portal) and reviews the requested permissions:
The admin sees the application/s waiting for approval
Upon clicking on the application, the request details showing the name of the application, the URL and developer information if applicable:
Also the requested by are displayed on screen:
The admin can then review the permissions requested and consent or deny this particular request (allowing another user to request later) or block this application from ever requesting access.
When the admin reviews the permissions, this is what the request might look like:
Note that the admin is warned that granting access to the particular app in this instance grants access to all users in the organisation:
