1

As per the title I can't find anywhere that explicitly gives me the information and my best guess was to use

https://graph.microsoft.com/v1.0/applications

and look at the requiredResourceAccess but that doesn't appear to provide the information about actual consent.

Is the mere presence of entries in here proof that admin consent was required, I'm going to guess at no as I added permissions to an app and even before granting consent the entries appeared in requiredResourceAccess and the entries didn't change when I granted consent.

Simon
  • 1,613
  • 1
  • 12
  • 27
  • please refer to this [similar question](https://stackoverflow.com/questions/63269627/microsoft-graph-fetching-app-permissions-based-on-appid/63290874#63290874) which may help you – Sruthi J Oct 02 '20 at 09:10

1 Answers1

2

When consent is granted for an application, three things may happen:

  1. A service principal (servicePrincipal) representing the identity of the client application (the one being given access) is created, if it didn't already exist.
  2. For every API to which the client application is granted delegated permissions, a delegated permission grant (oauth2PermissionGrant) is created.
  3. For every app-only permission client application is granted, a app role assignment* (appRoleAssignment) is created.

(Depending on which permission the app requires, #2 or #3 might be unnecessary.)

So, "what applications have been granted admin consent?" can be equated to "what service principals exist which have been granted tenant-wide delegated permissions, or app-only permissions?"

  1. To list all service principals in the tenant: 
    GET https://graph.microsoft.com/v1.0/servicePrincipals
  2. To get all tenant-wide delegated permissions granted to a given service principal: 
    GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants
       ?$filter=clientId eq {id} and consentType eq 'AllPrincipals'
  3. To get all app roles (app-only permissions) granted to a service principal: 
    GET https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments

To map the granted app role IDs or delegated permission scope values to the display names and descriptions, you can look up the granted app roles to the appRoles and oauth2PermissionScopes collections on the resource service principal (i.e. the service principal representing the API).

This can all be done with Azure AD PowerShell and wrapped into a function to dump out delegated and app-only permission grants. Here is an example: Get-AzureADPSPermissions.ps1

Philippe Signoret
  • 13,299
  • 1
  • 40
  • 58
  • Thanks I will take a look and let you know – Simon Oct 02 '20 at 09:27
  • I had looked at the servicePrincipals endpoint and appRoles but when I looked the appRoles were/are [] so I figured I wasn't properly understanding appRoles. However the appRoleAssignments does show me what I need and after testing I see that the assignment does only appear in the list once admin consent has been granted. Thanks, very useful. Script also works perfectly, thanks. Now just need a way to convert ids like "498476ce-e0fe-48b0-b801-37ba7e2685c6" to Organization.Read.All more readable values thru the Graph API if possible (I see your script does it so will investigate) – Simon Oct 02 '20 at 10:02
  • See the note in my answer: "To map the granted app role IDs or delegated permission scope values to the display names and descriptions, you can look up the granted app roles to the appRoles and oauth2PermissionScopes collections on the resource service principal (i.e. the service principal representing the API)." – Philippe Signoret Oct 02 '20 at 10:33
  • That was my issue originally oauth2PermissionScopes is populated but appRoles isn't even though appRoleAssignments returns data. For my example I have 1 item in /servicePrincipals/{id}/appRoleAssignments but in /servicePrincipals/{id} appRoles is []? – Simon Oct 02 '20 at 13:03
  • 1
    `servicePrincipals/{id}/appRoleAssignments` will return `resourceId`, `principalId`, and `appRoleId` for every assignment. `principalId` will be the same as `{id}`—it's the _client_. `resourceId` is the `id` of the API's service principal—the _resource_. `appRoleId` will map to an app role in the `appRoles` collection on the _resource_ service principal: `servicePrincipals/{resourceId}`. (So, check on the resource service principal, instead of on the client service principal.) – Philippe Signoret Oct 02 '20 at 17:32
  • Ahh I see and yes that's perfect, much appreciated. – Simon Oct 02 '20 at 19:58