À quoi cela sert ?

Dans certaines organisations, il est parfois nécessaire d’accorder à une application des permissions pour accéder à une API uniquement au nom d’un utilisateur précis, sans étendre ce consentement à l’ensemble du tenant. Cette approche est particulièrement utile pour des scénarios de test, des comptes dédiés, ou des usages restreints nécessitant un contrôle fin des accès. Microsoft Entra ID permet cela grâce à Microsoft Graph PowerShell, en créant une délégation ciblée de permissions associée à un utilisateur unique.

Script proposé par Microsoft

Microsoft fournit un script PowerShell destiné à appliquer, pour une application, un ensemble de permissions déléguées au nom d’un utilisateur précis.

Prérequis

• Un compte avec un rôle suffisant : Application Administrator, Cloud Application Administrator ou Privileged Role Administrator.
• L’ID de l’application cliente, l’ID de l’API et l’UPN ou ID de l’utilisateur ciblé.
• Le module Microsoft Graph PowerShell installé.

Script

# The app for which consent is being granted.
$clientAppId = "de8bc8b5-d9f9-48b1-a8ad-b748da725064" # Microsoft Graph Explorer

# The API to which access will be granted. Microsoft Graph Explorer makes API 
# requests to the Microsoft Graph API, so we'll use that here.
$resourceAppId = "00000003-0000-0000-c000-000000000000" # Microsoft Graph API

# The permissions to grant. Here we're including "openid", "profile", "User.Read"
# and "offline_access" (for basic sign-in), as well as "User.ReadBasic.All" (for 
# reading other users' basic profile).
$permissions = @("openid", "profile", "offline_access", "User.Read", "User.ReadBasic.All")

# The user on behalf of whom access will be granted. The app will be able to access 
# the API on behalf of this user.
$userUpnOrId = "user@example.com"

# Step 0. Connect to Microsoft Graph PowerShell. We need User.ReadBasic.All to get
#    users' IDs, Application.ReadWrite.All to list and create service principals, 
#    DelegatedPermissionGrant.ReadWrite.All to create delegated permission grants, 
#    and AppRoleAssignment.ReadWrite.All to assign an app role.
#    WARNING: These are high-privilege permissions!
Connect-MgGraph -Scopes ("User.ReadBasic.All Application.ReadWrite.All " + "DelegatedPermissionGrant.ReadWrite.All " + "AppRoleAssignment.ReadWrite.All")

# Step 1. Check if a service principal exists for the client application. 
#     If one doesn't exist, create it.
$clientSp = Get-MgServicePrincipal -Filter "appId eq '$($clientAppId)'"
if (-not $clientSp) {
   $clientSp = New-MgServicePrincipal -AppId $clientAppId
}

# Step 2. Create a delegated permission that grants the client app access to the
#     API, on behalf of the user. (This example assumes that an existing delegated 
#     permission grant does not already exist, in which case it would be necessary 
#     to update the existing grant, rather than create a new one.)
$user = Get-MgUser -UserId $userUpnOrId
$resourceSp = Get-MgServicePrincipal -Filter "appId eq '$($resourceAppId)'"
$scopeToGrant = $permissions -join " "
$grant = New-MgOauth2PermissionGrant -ResourceId $resourceSp.Id -Scope $scopeToGrant -ClientId $clientSp.Id -ConsentType "Principal" -PrincipalId $user.Id

# Step 3. Assign the app to the user. This ensures that the user can sign in if assignment
#     is required, and ensures that the app shows up under the user's My Apps portal.
if ($clientSp.AppRoles | ? { $_.AllowedMemberTypes -contains "User" }) {
    Write-Warning ("A default app role assignment cannot be created because the " + "client application exposes user-assignable app roles. You must " + "assign the user a specific app role for the app to be listed " + "in the user's My Apps portal.")
} else {
    # The app role ID 00000000-0000-0000-0000-000000000000 is the default app role
    # indicating that the app is assigned to the user, but not for any specific 
    # app role.
    $assignment = New-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $clientSp.Id -ResourceId $clientSp.Id -PrincipalId $user.Id -AppRoleId "00000000-0000-0000-0000-000000000000"
}

Conclusion

Bien que ce mécanisme soit efficace pour des besoins très ciblés, il doit être utilisé de manière prudente. Le consentement est appliqué immédiatement, sans validation de l’utilisateur, ce qui peut amplifier les risques en cas de permissions sensibles. Cette méthode n’est pas adaptée pour remplacer un consentement administrateur global dès que l’application s’adresse à un ensemble étendu d’utilisateur.