How to Use Separate Apps to Control Access to the Microsoft Graph PowerShell SDK

Use Apps to Control the Permissions Users Have for Interactive Graph Sessions

By default, when an administrator runs the Connect-MgGraph cmdlet to create a delegated interactive Graph session, they authenticate using the Microsoft Graph Command Line Tools enterprise app. Usually, everything works well, even if permissions creep can be an issue.

Large organizations that want to limit interactive access to the Microsoft Graph PowerShell SDK should consider creating separate registered apps for this purpose. This is especially true when organizations need tailored access to the Microsoft Graph PowerShell SDK. For example, help desk personnel might need permission to manage users, groups, and devices but should not have access to other Microsoft 365 data.

Each app can have its own set of user and group assignments to control the ability to use the app to run interactive Graph sessions, and its own set of Graph permissions to allow access to data.

Using Registered Apps

A registered app is created and controlled by the tenant. Like the Microsoft Graph Command Line Tools, a registered app’s service principal holds the permissions available to users who connect to the Graph through that app.

Like the enterprise app, the organization controls the permissions consented to for each registered app. An app therefore becomes the key element to enable granular management of permissions in line with the principle of access via least privileged permission.

To create a registered app to run limited Microsoft Graph PowerShell SDK interactive sessions:

  • Open the Entra admin center in the App Registrations section. Create a new app registration, assign a suitable name, and register the application. Make sure to assign at least one application owner. It’s also a good idea to configure a suitable application icon.
  • Access the app and open the Authentication tab. Under the Redirect URI configuration tab, choose Add Redirect URI, then Mobile and desktop applications. See below for more information. Remember to click configure to add the redirect URI to the app.
  • Add the Graph delegated permissions the designated accounts can use, like Directory.Read.All and User.Read.All and grant consent for the permissions.  Remember that the app only supports delegated access. Users are therefore limited to data that they are authorized to access. To work with tenant-wide objects such as groups, reports, and directory data, assigned users will also require appropriate Entra role assignments.
  • Go to the Enterprise applications section, locate the app’s service principal, go to the Properties page and set the Assignment required? property to Yes. This setting makes user or group assignment mandatory before accounts can use the app.
  • Still in the Enterprise app, open the Users and groups tab and add the users and groups who should have access to the app. It’s recommended that you use a security group to control access to the app. The user and group assignments are applied to the service principal because the service principal enforces access to the application within the tenant.
  • After the app is configured and assignments are in place, authorized users can sign in to Microsoft Graph interactive sessions through the app. To instruct the Connect-MgGraph cmdlet to connect using the registered app rather than the default Microsoft Graph Command Line Tools enterprise app, include the tenant identifier and application identifier. For example:

Connect-MgGraph -TenantId mytenant.com -AppId a69635f3-3ac8-4949-a82b-f31b396de57b
  • Repeat the process to create and configure a registered app for each team that requires tailored access to the Microsoft Graph PowerShell SDK.

It’s possible to have too much of a good thing by creating a proliferation of registered apps for different users. Every app must be managed, and administrators should conduct periodic reviews of the permissions assigned to the registered apps used with the Microsoft Graph PowerShell SDK to ensure that the apps do not accumulate unnecessary permissions over time and experience the same permission creep often seen with the Microsoft Graph Command Line Tools enterprise application.

Redirect URIs

Prior to the introduction of Web Account Manager (WAM) support for the Microsoft Graph PowerShell SDK (soon to be the default for all interactive Graph sessions with the default app), the redirect URI used for apps that wished to connect to the Graph was https://login.microsoftonline.com/common/oauth2/nativeclient. This value still works with PowerShell V5.1. However, if you use PowerShell Core, WAM uses a different authentication flow, and the nativeclient redirect results in an AADSTS50011 error.

Microsoft’s documentation says that using http://localhost together with a WAM broker redirect URI of the form ms-appx-web://Microsoft.AAD.BrokerPlugin/<AppId> is the right approach. Figure 1 shows an example of the full configuration.

Redirect URIs for a Microsoft Graph PowerShell SDK app with WAM.

Configuring apps for interactive Graph sessions.
Figure 1: Redirect URIs for a Microsoft Graph PowerShell SDK app with WAM

Assigning Users to use an App for Graph Sessions

The Get-MgServicePrincipalAppRoleAssignedTo cmdlet can be used to report the set of user accounts that have direct assignments for an app. This example uses the Get-MgServicePrincipal cmdlet to find the identifier for the app’s service principal, which is then used to find the assignees. Two assignees are present. One is the tenant administrator. The other assignee is a security group. Each assignee has an app role of Default Access (00000000-0000-0000-0000-000000000000), which is all that’s needed to run the app.

$GraphSDKApp = Get-MgServicePrincipal -filter "displayname eq 'HelpDeskGraphSDK'"

$GraphSDKApp | Format-Table DisplayName, Id

DisplayName         Id
--------------      --
Help Desk Graph SDK 0c593b15-ec27-4481-9e12-31777c9f6503

$Assignees = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $GraphSDKApp.Id

$Assignees | Format-Table CreatedDateTime, PrincipalDisplayName, AppRoleId

CreatedDateTime     PrincipalDisplayName       AppRoleId
---------------     --------------------       ---------
07/09/2026 09:04:54 Tenant Administrator       00000000-0000-0000-0000-000000000000
07/09/2026 09:03:00 Help Desk Graph SDK Access 00000000-0000-0000-0000-000000000000

You can also add direct assignments for an app with the New-MgUserAppRoleAssignment cmdlet. Here’s an example:

$SP = Get-MgServicePrincipal -filter "DisplayName eq 'HelpDeskGraphSDK'"
$DefaultRoleId = "00000000-0000-0000-0000-000000000000"
$User = Get-MgUser -UserId Kim.Akers@office365itpros.com

New-MgUserAppRoleAssignment -UserId $User.Id -AppRoleId $DefaultRoleId -PrincipalId $User.Id -ResourceId $SP.Id

Figure 2 shows a delegated session created with PowerShell Core using Microsoft Graph PowerShell SDK V2.39. The user has signed in but has a limited set of permissions, including User.ReadBasic.All to allow them to see some details of user accounts across the tenant. The User.ReadBasic.All permission doesn’t support filtering against the UserType property, so the attempt to find member accounts fails.

Using a delegated Graph session with a custom app.
Figure 2: Using a delegated Graph session with a custom app

Complimentary to the above, it’s also a good idea to secure the default Microsoft Graph Command Line Tools app to make sure that only certain users are authorized to run it. There’s no point in leaving the default app wide open when you’re busily creating new apps to give restricted access to designated teams.


Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.