Removing Permissions from the Graph Explorer

Too Many Graph Explorer Permissions Can Get in the Way

The Microsoft Graph Explorer is an excellent web-based tool for debugging Graph API requests. I can’t tell you how many times I have used the Graph Explorer to figure out the syntax needed to make a request work, or even to do real work, such as customizing the Microsoft 365 user profile card. Microsoft continues to add new features to the Graph Explorer to make it even better. The example queries are especially useful as they can be run against data from your tenant (if you sign in) or sample data.

One problem that the Graph Explorer shares with interactive sessions using the Microsoft Graph PowerShell SDK is permission accumulation. Over time, different permissions are necessary to run Graph requests. The consents granted to use those permissions accrue until the service principal (enterprise app) for the Graph Explorer (application identifier de8bc8b5-d9f9-48b1-a8ad-b748da725064) become excessive. Figure 1 shows the current permission status for the Graph Explorer in my tenant. My only explanation is that I do a lot of testing.

One quick way to clear all the permissions is to close the Graph Explorer window and then delete the Graph Explorer app. Wait a few minutes afterwards and then launch the Graph Explorer and sign-in again. The Explorer detects that its app isn’t available in the tenant and will recreate it with no consented permissions. The same technique works for the Microsoft Graph PowerShell SDK app.

The Problem of Too Many Permissions

Although it might seem good that the Graph Explorer should have the permissions necessary to run requests against many different types of Microsoft 365 data, too many permissions can get in the way. Take the situation where you use the Graph Explorer to test a request and are delighted when the request runs and returns data. Assuming that all is well, you go ahead and use the request in a PowerShell script only to discover that the script fails when it runs because the app it uses to authenticate for Graph requests doesn’t have the right permissions. The Graph Explorer had the necessary permission but you never knew (or checked) that an app must have consent for a specific permission to run the request you tested.

The least permission model used by the Graph can sometimes make it difficult to figure out exactly what permission an individual request requires. A further complexity is that the Graph Explorer uses delegated permissions rather than application permissions, so a lot of what the Explorer can do depends on the roles held by the signed-in account.

Clean Up Graph Explorer Permissions

In any case, to save bruised egos and ensure that testing reveals exactly what permissions are necessary, you can clean up the permissions held by the Graph Explorer. One way to do this is to remove permissions through the Microsoft Entra admin center, just like you’d do for any other registered app. The other is to use the Consent to permissions option in the Graph Explorer, revealed by clicking the avatar for the signed in user (Figure 2).

The option opens a page to browse Graph permissions. You can consent to permissions that the Graph Explorer does not have or unconsent to permissions that it does. In Figure 3, we see the set of Mail Graph permissions, three of which are held by the Graph Explorer (probably used when debugging my mailbox clean up script). When you see AllPrincipal listed against a permission, it means that an administrator granted consent. Principal means that a user granted consent.

When testing with the Graph Explorer, my first step now is to check the permissions already in place and remove any that I think might interfere with testing. I can then gradually add permissions back to establish the exact set of permissions required to allow a Graph request to run. After making changes, you must sign-out and sign back in again to pick up the refreshed permission set (in an access token).

One point to remember is that you can’t remove the User.Read permission because that’s needed to sign into the Graph Explorer.

Permission Accrual is Bad

It’s easier to leave permissions in place but this practice will lead to problems. Treat Graph Explorer as a tool to help you understand how Graph requests work, including the permissions needed to run, and clean up between projects. (And yes, the same advice applies to the app used by the Microsoft Graph PowerShell SDK).

---

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.