Conceder consentimento em nome de um único utilizador utilizando o PowerShell

Neste artigo, você aprenderá a conceder o consentimento em nome de um único utilizador usando o PowerShell.

Quando um utilizador concede o consentimento para si mesmo, os seguintes eventos ocorrem

  1. É criado um principal de serviço para a aplicação do cliente, se já não existir. Um diretor de serviço é o caso de um pedido ou um serviço no seu inquilino Azure Ative Directory (Azure AD). O acesso que é concedido à app ou serviço está associado a este objeto principal de serviço.

  2. Para cada API a que a aplicação necessita de acesso, é criada uma autorização delegada a essa API para as permissões que são necessárias pela aplicação, para acesso em nome do utilizador. Uma autorização delegada autoriza um pedido de acesso a uma API em nome de um utilizador, quando esse utilizador se inscreveu.

  3. O utilizador é atribuído à aplicação do cliente. A atribuição da aplicação ao utilizador garante que a aplicação está listada no portal My Apps para esse utilizador, o que lhes permite rever e revogar o acesso que foi concedido em seu nome.

Pré-requisitos

Para conceder o consentimento a um pedido em nome de um utilizador, precisa:

  • Uma conta de utilizador com Administrador Global, Administrador de Aplicação ou Administrador de Aplicação cloud

Antes de começar, grave os seguintes detalhes do portal Azure:

  • O ID da aplicação para a aplicação que está a conceder consentimento. Para efeitos deste artigo, vamos chamá-lo de "aplicação de cliente".
  • As permissões da API que são exigidas pela aplicação do cliente. Descubra o ID da aplicação da API e os IDs de permissão ou valores de reclamação.
  • O nome de utilizador ou iD do objeto para o utilizador em nome de quem será concedido o acesso.

Para este exemplo, usaremos o Microsoft Graph PowerShell para conceder o consentimento em nome de um único utilizador. A aplicação do cliente é Microsoft Graph Explorer, e concedemos acesso à Microsoft Graph API.

# The app for which consent is being granted. In this example, we're granting access
# to Microsoft Graph Explorer, an application published by Microsoft.
$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 does not 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.
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 access panel.")
} 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"
}

Passos seguintes