Informazioni sulle autorizzazioni e sul consenso di Microsoft Graph

  • 6 minuti

Per sviluppare un'applicazione del cliente che recupera i dati Microsoft 365, è necessario comprendere il funzionamento delle autorizzazioni e del consenso in Microsoft Graph. Si ponga il caso in cui si vogliono scegliere i dati a cui l'applicazione può accedere e a cui non può accedere. Ad esempio, se si vogliono mostrare le prossime riunioni di un venditore connesso, è necessario che l'applicazione abbia l'autorizzazione per accedere ai dati del calendario da Microsoft 365.

Le applicazioni richiedono autorizzazioni per accedere a risorse Microsoft 365 specifiche tramite Microsoft Graph. Tali richieste possono essere effettuate in anticipo (quando l'applicazione è registrata) o dinamicamente (quando l'applicazione è in esecuzione). Quando un'applicazione richiede l'autorizzazione, un utente o un amministratore deve dare il consenso all'autorizzazione prima che Microsoft Graph autorizzi le richieste.

Esistono tre concetti principali per comprendere quando l'applicazione deve interagire con Microsoft Graph:

  • Autorizzazioni o ambiti di Microsoft Graph
  • Tipi di autorizzazione
  • Token di accesso

Autorizzazioni o ambiti di Microsoft Graph

Le autorizzazioni di Microsoft Graph contengono ambiti che controllano l'accesso dell'applicazione a risorse specifiche, ad esempio utenti, posta elettronica e file. Gli ambiti controllano anche le operazioni che possono essere eseguite su tali risorse. Il seguente modello di esempio definisce un'autorizzazione per un'operazione di Microsoft Graph per una risorsa:

Resource-name.operation.constraint

Ad esempio, User.Read.All concede a un'applicazione l'autorizzazione per leggere il profilo di tutti gli utenti in una directory. Per leggere il profilo di un utente connesso, l'autorizzazione necessaria è User.Read.

Tipi di autorizzazione

Nell'ID Microsoft Entra sono disponibili due tipi di autorizzazioni:

  • L'applicazione usa autorizzazione delegata quando effettua una chiamata Microsoft Graph per conto dell'utente. L'utente può fornire il consenso ad alcuni ambiti di autorizzazione, ad esempio User.Read. Tuttavia, alcuni ambiti di autorizzazione hanno privilegi elevati e richiedono il consenso di un amministratore. Un esempio di ambito di autorizzazione con privilegi elevati è Channel.Delete.All, che elimina i canali in qualsiasi team per conto dell'utente connesso.

    L'esempio più semplice di ambito di autorizzazione delegata è User.Read, necessario per chiamare/me l'endpoint. In Microsoft Graph, tutte le chiamate API con /me usano il contesto dell'utente attualmente connesso.

  • L'autorizzazione dell'applicazione non richiede un utente connesso all'applicazione. Viene spesso usato quando un utente non è presente, ad esempio in un processo in background o per elevare le autorizzazioni. Un amministratore approva in anticipo l'autorizzazione.

    Un esempio di ambito di autorizzazione dell'applicazione è Calendars.ReadWrite, che consente all'applicazione di creare, leggere, aggiornare ed eliminare eventi di tutti i calendari senza un utente connesso. Non è possibile usare un'API /me per un ambito di autorizzazione dell'applicazione, perché non esiste alcun utente connesso per estrarre tali informazioni.

Token di accesso

Dopo che l'applicazione ha richiesto l'autorizzazione e un utente o un amministratore ha acconsentito, l'applicazione può ottenere un token di accesso da Microsoft Identity Platform. È possibile considerare il token di accesso come un biglietto del cinema che si assegna a un operatore per dimostrare di aver pagato per vedere il film. L'applicazione fornisce un token di accesso a Microsoft Graph per dimostrare di avere l'autorizzazione per accedere ai dati di Microsoft 365.

Microsoft Graph richiede un token di accesso valido nell'intestazione HTTP di ogni richiesta. Viene passata nell'intestazione di autorizzazione di ogni richiesta con la parola "Bearer" e uno spazio che la precede. Si tratta di un promemoria che, come il biglietto del cinema, il bearer può usare per ottenere il token di accesso. Ovvero, chiunque abbia il biglietto può accedere senza dimostrare la propria identità. Per questo motivo, Microsoft Graph richiede la crittografia HTTPS per tutte le richieste. Analogamente ai biglietti del cinema, i token di accesso sono validi solo per un breve periodo, in genere un'ora.

Ecco un esempio dell'aspetto di un'intestazione di autorizzazione per una richiesta di Microsoft Graph:

GET https://graph.microsoft.com/v1.0/me/ HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer EwAoA8l6BAAU ... 7PqHGsykYj7A0XqHCjbKKgWSkcAg==