The Azure port still uses the Azure AD Graph API in some places. One thing it uses this for is to list API permissions. For this, the portal uses the REST API target GET https://graph.windows.net/myorganization/applicationRefs/c5393580-f805-4401-95e8-94b7a6ef2fc2?api-version=2.0
(example shown for Office 365 Management API). I've searched and cannot seem to find a way to list similar permission sets using the Microsoft Graph API. Is there a way to access this using the Microsoft Graph API?

- 2,127
- 5
- 20
- 25
-
Could you share the link to the example? – unknown Dec 29 '20 at 01:35
-
I'm confused what you mean by a link to the example. The URL example I provided in the original question. Another example for Microsoft Graph permissions using curl: `curl 'https://graph.windows.net/myorganization/applicationRefs/00000003-0000-0000-c000-000000000000?api-version=2.0' -H 'Authorization: Bearer
` – mike_b Dec 29 '20 at 05:58 -
I mean the official document about applicationRefs. I couldn't find the API in Azure AD Graph API. – unknown Dec 29 '20 at 06:04
-
Hi, may I know if the solution I provided below helps your problem ? – Hury Shen Jan 06 '21 at 08:33
-
Any update ? If still have any problem, please let me know. – Hury Shen Jan 08 '21 at 01:40
2 Answers
Ok, was going to upvote one of the previous answers, but my profile is too new. :( You can do this by reading the MS Graph service principal in your tenant as described above. This PowerShell code gives an example (it's used in a command called Find-GraphPermission
in the autographps
and autographps-sdk
modules.
Basic approach is:
- Get app-only permissions from the
appRoles
property of theservicePrincipal
- Get delegated permissions from the
publishedPermissionScopes
property - Each element of
appRoles
has an id that can be read or written from a givenappRoleAssigment
object on an app'sservicePrincipal
in your tenant. Note that eachappRole
element has avalue
property that is the common friendly name of the app-only permission (e.g.BitlockerKey.ReadBasic.All
- A similar
id
andvalue
pair exists for each element ofpublishedPermissionScopes
which gives you the delegated permissions. You can use those ids withoauth2PermissionGrant
objects under the segment/oauth2PermissionGrants
to enumerate consent grants for a givenservicePrincipal
(and thusapp
) in your tenant or grant or remove consent
Note that the ids for both appRoles
and publishedPermissionScopes
are the same in all tenants, so you can actually perform this same mapping of friendly names to ids for any tenant, and use a static snapshot. This can be useful as your application may not be able to read the Microsoft Graph servicePrincipal
object. If you store a static version, you'll have the mapping regardless and you'll only miss any new permissions that get added to Microsoft Graph for new APIs.
This file contains a snapshot of the MS Graph servicePrincipal
as a fairly readable JSON-like PowerShell hash table: https://github.com/adamedx/autographps-sdk/blob/main/src/common/DefaultScopeData.ps1

- 41
- 2
For this requirement, you can use this microsoft graph api: https://graph.microsoft.com/v1.0/applications/<object id of the application>
It will response the result like below screenshot(please pay attention to the field requiredResourceAccess
):
The content under requiredResourceAccess
is the API permissions of this application. The type scope
means the permission is Delegated type and the type role
means the permission is Application type.
Then please refer to steps below to know which permission does the id
under resourceAccess
field refer to.
Copy the
resourceAppId
, in my screenshot is00000003-0000-0000-c000-000000000000
. And request the graph api:https://graph.microsoft.com/v1.0/serviceprincipals?$filter=appId eq '00000003-0000-0000-c000-000000000000'
Copy one of the
id
underresourceAccess
field in the response of first graph api. For example copy the first ida154bxxxxxxxxxxx59
in my first screenshot. And then search this id in the response of second graph api, we can find this id refer toUser.Read.All
permission.

- 14,948
- 1
- 9
- 18
-
This does not work for third-party installed applications. First, `v1.0/applications/` cannot be used to pull installed application info from another tenant. Second, when I take the appId / service principal ID from the external application and use that to search under `v1.0/serviceprincipals`, the resulting `appRoles` and `oauth2PermissionScopes` arrays are empty. What you describe works fine for locally installed / developed applications where the service principal identity is in the tenant. But it doesn't work for installed external applications. – mike_b Jan 08 '21 at 17:22
-
Note that `beta/servicePrincipals/{id}/appRoleAssignments` almost gets us there, but it doesn't provide the readable name for a permission/scope. – mike_b Jan 08 '21 at 17:23