Scoprire autorizzazioni e consenso

  • 3 minuti

Le applicazioni che si integrano con Microsoft Identity Platform seguono un modello di autorizzazione che consente a utenti e amministratori di controllare l'accesso ai dati.

Microsoft Identity Platform implementa il protocollo di autorizzazione OAuth 2.0. OAuth 2.0 è un metodo tramite cui un'applicazione di terze parti può accedere alle risorse ospitate sul Web per conto di un utente. Tutte le risorse ospitate sul Web che si integrano con Microsoft Identity Platform possiedono un identificatore o URI dell'ID applicazione.

Ecco alcuni esempi di risorse Microsoft ospitate sul Web:

  • Microsoft Graph: https://graph.microsoft.com
  • Microsoft 365 Mail API: https://outlook.office.com
  • Azure Key Vault: https://vault.azure.net

Lo stesso vale per le risorse di terze parti integrate con Microsoft Identity Platform. Tali risorse possono anche definire un set di autorizzazioni che può essere usato per suddividere le funzionalità di tale risorsa in blocchi più piccoli. Quando una funzionalità della risorsa è suddivisa in set di autorizzazioni di dimensioni minori, è possibile creare le app di terze parti affinché vengano richieste solo le autorizzazioni necessarie per il relativo funzionamento. Utenti e amministratori possono conoscere i dati a cui l’applicazione può accedere.

In OAuth 2.0 questi tipi di set di autorizzazioni sono denominati ambiti. Spesso anche autorizzazioni. In Microsoft Identity Platform un'autorizzazione è rappresentata come valore stringa. Un'applicazione richiede le autorizzazioni necessarie specificandole nel parametro di query scope. Identity Platform supporta diversi ambiti di OpenID Connect ben definiti e le autorizzazioni basate sulle risorse (ogni autorizzazione è indicata aggiungendo il valore dell'autorizzazione all'identificatore di risorsa o all'URI dell'ID applicazione). La stringa di autorizzazione https://graph.microsoft.com/Calendars.Read, ad esempio, viene usata per richiedere l'autorizzazione per leggere i calendari dell'utente in Microsoft Graph.

Un'app richiede in genere queste autorizzazioni specificando gli ambiti nelle richieste all'endpoint di autorizzazione Microsoft Identity Platform. Tuttavia, alcune autorizzazioni con privilegi elevati possono essere concesse solo tramite il consenso dell’amministratore. Possono essere richieste o concesse usando l'endpoint di consenso dell'amministratore.

Nota

Nelle richieste agli endpoint di autorizzazione, token o consenso per Microsoft Identity Platform, se l'identificatore viene omesso nel parametro di ambito, si presuppone che la risorsa sia Microsoft Graph. Ad esempio, scope=User.Read equivale a https://graph.microsoft.com/User.Read.

Tipi di autorizzazione

Microsoft Identity Platform supporta due tipi di autorizzazioni: autorizzazioni delegate e accesso solo app.

  • Le autorizzazioni delegate vengono usate dalle app che hanno un utente connesso. Per queste app, l'utente o un amministratore fornisce il consenso per le autorizzazioni richieste dall'app. L'app viene delegata con l'autorizzazione ad agire come utente connesso quando effettua chiamate alla risorsa di destinazione.

  • Le autorizzazioni di accesso solo app sono usate dalle app che vengono eseguite senza un utente connesso, ad esempio le app eseguite come servizi in background o daemon. Solo un amministratore può concedere il consenso per le autorizzazioni di accesso solo app.

Le applicazioni in Microsoft Identity Platform si basano sul consenso per ottenere l'accesso alle API o alle risorse necessarie. Ci sono molti tipi di consenso che l'app deve riconoscere per funzionare correttamente. Se si definiscono le autorizzazioni, è anche necessario comprendere in che modo gli utenti possono accedere all'app o all'API.

Esistono tre tipi di consenso: consenso utente statico, consenso utente incrementale e dinamico e consenso amministratore.

Nello scenario di un consenso utente statico è necessario specificare tutte le autorizzazioni necessarie nella configurazione dell'app nel portale di Azure. Se l'utente (o l'amministratore, se appropriato) non ha concesso il consenso per questa app, Microsoft Identity Platform chiede all'utente di fornire il consenso in questo momento. Le autorizzazioni statiche consentono anche agli amministratori di concedere il consenso per conto di tutti gli utenti dell'organizzazione.

Nonostante la definizione delle autorizzazioni statiche dell'app nel portale di Azure consenta di mantenere il codice chiaro e semplice, questa opzione può presentare problemi per gli sviluppatori:

  • Al primo accesso dell'utente l'app deve richiedere tutte le autorizzazioni di cui potrebbe avere bisogno. Questo può richiedere di creare un lungo elenco di autorizzazioni che dovevano essere approvate dall'utente al primo accesso, causando spesso la rinuncia all'accesso da parte di quest'ultimo.

  • L'app deve conoscere in anticipo tutte le risorse a cui potrebbe dover accedere. È difficile creare applicazioni che possano accedere a un numero arbitrario di risorse.

Tramite l’endpoint di Microsoft Identity Platform è possibile ignorare le autorizzazioni statiche nelle informazioni di registrazione delle app sul portale Azure e richiedere invece le autorizzazioni in modo incrementale. È possibile richiedere anticipatamente un set minimo di autorizzazioni e richiederne altre man mano che il cliente usa più funzionalità dell'app.

A tale scopo è possibile specificare gli ambiti necessari per l'app in qualsiasi momento, inclusi i nuovi ambiti nel parametro scope quando si richiede un token di accesso, senza doverli definire in precedenza nelle informazioni di registrazione dell'applicazione. Se l'utente non ha ancora fornito il consenso per i nuovi ambiti aggiunti alla richiesta, gli viene chiesto di farlo solo per le nuove autorizzazioni. Il consenso incrementale o dinamico si applica solo alle autorizzazioni delegate e non alle autorizzazioni di accesso solo app.

Importante

Il consenso dinamico può risultare comodo, ma presenta un'importante sfida per le autorizzazioni che richiedono il consenso dell'amministratore, perché nell'esperienza di consenso dell'amministratore tali autorizzazioni non sono note al momento del consenso. Se sono necessarie le autorizzazioni con privilegio di amministratore o se l'app usa il consenso dinamico, è necessario registrare tutte le autorizzazioni nel portale di Azure (non solo il sottoinsieme delle autorizzazioni che richiedono il consenso dell'amministratore). Ciò consente agli amministratori del tenant di fornire il consenso per conto di tutti gli utenti.

Il consenso amministratore è necessario quando l'app deve accedere a determinate autorizzazioni con privilegi elevati. Il consenso dell'amministratore garantisce che gli amministratori dispongano di altri controlli prima di autorizzare le app o gli utenti ad accedere a dati dell'organizzazione che richiedono privilegi elevati.

Il consenso amministratore eseguito per conto di un'organizzazione richiede comunque autorizzazioni statiche registrate per l'app. Se è necessario un amministratore per fornire il consenso a nome di tutta l’organizzazione, impostare tali autorizzazioni per applicazioni nel portale di registrazione delle app. Questo riduce i cicli richiesti dall'amministratore dell'organizzazione per configurare l'applicazione.

In una richiesta di autorizzazione OpenID Connect o OAuth 2.0, un'app può richiedere le autorizzazioni necessarie usando il parametro di query scope. Ad esempio, quando un utente accede a un'app, questa può inviare una richiesta simile alla seguente. Le interruzioni di riga servono per agevolare la leggibilità.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

Il parametro scope è un elenco di autorizzazioni delegate separate da spazi richieste dall'app. Ogni autorizzazione viene indicata aggiungendo il valore dell'autorizzazione all'identificatore di risorsa (URI dell'ID applicazione). Nella richiesta di esempio l'app richiede l'autorizzazione per la lettura del calendario dell'utente e l'invio di messaggi di posta elettronica come utente.

Dopo che l'utente immette le proprie credenziali, Microsoft Identity Platform controlla se è presente un record corrispondente di consenso utente. Se l'utente non ha fornito il consenso per nessuna delle autorizzazioni richieste in passato o se un amministratore non ha dato il proprio consenso per queste autorizzazioni per conto dell'intera organizzazione, Microsoft Identity Platform chiede all'utente di concedere le autorizzazioni richieste.