Configurare l'autorizzazione per un'applicazione

  • 1 minuto

Gli amministratori dovranno configurare le autorizzazioni e il consenso nell'endpoint di Microsoft Identity Platform.

Le applicazioni che si integrano con Microsoft Identity Platform seguono un modello di autorizzazione che offre a utenti e amministratori il controllo sulle modalità di accesso ai dati. L'implementazione del modello di autorizzazione è stata aggiornata nell'endpoint Microsoft Identity Platform, modificando la modalità di interazione di un'app con questa piattaforma. Questa unità illustra i concetti di base di questo modello di autorizzazione, inclusi ambiti, autorizzazioni e consenso.

Ambiti e autorizzazioni

Microsoft Identity Platform implementa il protocollo di autorizzazione OAuth 2.0, un metodo tramite cui un'app di terze parti può accedere alle risorse ospitate nel 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. Le risorse Microsoft ospitate nel Web includono ad esempio:

  • 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. Microsoft Graph ha ad esempio autorizzazioni definite per attività come le seguenti:

  • Lettura del calendario di un utente.
  • Scrittura nel calendario di un utente.
  • Invio di posta come utente.

Quando l'app definisce questi tipi di autorizzazioni, la risorsa può avere un controllo accurato dei dati e dell'esposizione delle funzionalità API. Un'app di terze parti può richiedere queste autorizzazioni a utenti e amministratori, che devono approvare la richiesta affinché l'app possa accedere ai dati o agire per conto di un utente. L'organizzazione di sviluppo dell'app può inserire le funzioni delle risorse in set di autorizzazioni più piccoli, gli sviluppatori possono creare app di terze parti che richiedono solo le autorizzazioni specifiche necessarie per il loro funzionamento. Utenti e amministratori possono sapere esattamente a quali dati ha accesso l'app e possono avere una maggiore certezza che l'app non agisca con finalità dannose. Gli sviluppatori devono sempre rispettare il concetto di privilegio minimo, richiedendo solo le autorizzazioni necessarie per il funzionamento delle loro applicazioni.

In OAuth 2.0 questi tipi di autorizzazioni vengono definiti ambiti o Spesso anche autorizzazioni. In Microsoft Identity Platform un'autorizzazione è rappresentata come valore stringa. Nell'esempio relativo a Microsoft Graph il valore stringa per ogni autorizzazione è:

  • Lettura del calendario di un utente tramite Calendars.Read
  • Scrittura nel calendario di un utente tramite Calendars.ReadWrite
  • Invio di posta come utente tramite Mail.Send

Un'app richiede in genere queste autorizzazioni specificando gli ambiti nelle richieste all'endpoint di autorizzazione Microsoft Identity Platform. Alcune autorizzazioni con privilegi elevati possono tuttavia venire concesse solo tramite il consenso amministratore e la richiesta e la concessione devono avvenire tramite l'endpoint di consenso amministratore.

Tipi di autorizzazione

Microsoft Identity Platform supporta due tipi di autorizzazioni: autorizzazioni delegate e autorizzazioni dell'applicazione.

  • 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 e all'app viene delegata l'autorizzazione per agire per conto dell'utente connesso quando vengono effettuate chiamate alla risorsa di destinazione. Alcune autorizzazioni delegate possono essere concesse da utenti senza privilegi di amministratore, mentre altre con privilegi più elevati richiedono il consenso dell'amministratore. Per informazioni sui ruoli di amministratore che possono fornire il consenso per le autorizzazioni delegate, vedere Autorizzazioni del ruolo di amministratore in Microsoft Entra ID.
  • Le autorizzazioni dell'applicazione 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 alle autorizzazioni dell'applicazione.

Le autorizzazioni valide sono quelle di cui l'app disporrà quando vengono effettuate richieste alla risorsa di destinazione. È importante comprendere la differenza tra le autorizzazioni delegate e dell'applicazione concesse all'app e le autorizzazioni valide quando vengono effettuate chiamate alla risorsa di destinazione.

  • Per le autorizzazioni delegate, le autorizzazioni valide dell'app sono costituite dall'intersezione con meno privilegi tra le autorizzazioni delegate concesse all'app (tramite il consenso) e i privilegi dell'utente attualmente connesso. L'app non può mai avere più privilegi rispetto all'utente connesso. All'interno delle organizzazioni, i privilegi dell'utente connesso vengono determinati da criteri o dall'appartenenza a uno o più ruoli di amministratore. Per informazioni sui ruoli di amministratore che possono fornire il consenso per le autorizzazioni delegate, vedere Autorizzazioni del ruolo di amministratore in Microsoft Entra ID.
  • Si supponga, ad esempio, che all'app sia stata concessa l'autorizzazione delegata User.ReadWrite.All. Questa autorizzazione concede nominalmente all'app l'autorizzazione per leggere e aggiornare il profilo di ogni utente in un'organizzazione. Se l'utente connesso è un amministratore globale, l'app sarà in grado di aggiornare il profilo di tutti gli utenti dell'organizzazione. Se tuttavia l'utente connesso non ha un ruolo di amministratore, l'app sarà in grado di aggiornare solo il profilo di tale utente. Non sarà possibile aggiornare i profili di altri utenti dell'organizzazione, perché l'utente per conto di cui è autorizzata ad agire non dispone di tali privilegi.
  • Per le autorizzazioni dell'applicazione, le autorizzazioni valide dell'app corrispondono al livello completo di privilegi impliciti nell'autorizzazione. Un'app che ha l'autorizzazione dell'applicazione User.ReadWrite.All può ad esempio aggiornare il profilo di tutti gli utenti dell'organizzazione.

Ambiti di OpenID Connect

L'implementazione di OpenID Connect in Microsoft Identity Platform presenta alcuni ambiti ben definiti ospitati anche in Microsoft Graph: openid, email, profile e offline_access. Gli ambiti address e phone di OpenID Connect non sono supportati.

In seguito alla richiesta di un token e degli ambiti OIDC verrà fornito un token per chiamare l'endpoint UserInfo.

Openid

Se un'app esegue l'accesso usando OpenID Connect, deve richiedere l'ambito openid. L'ambito openid viene visualizzato nella pagina di consenso dell'account aziendale come autorizzazione sign you in e nella pagina di consenso dell'account Microsoft personale come autorizzazione per la visualizzazione del profilo e la connessione ad app e servizi tramite l'account Microsoft. Questa autorizzazione consente a un'app di ricevere un identificatore univoco per l'utente sotto forma di attestazione secondaria e concede all'app l'accesso all'endpoint delle informazioni utente. L'ambito openid può essere usato nell'endpoint di token Microsoft Identity Platform per acquisire i token ID, che possono essere usati dall'app per l'autenticazione.

posta elettronica

L'ambito email può essere usato con l'ambito openid e con tutti gli altri. Consente all'app di accedere all'indirizzo e-mail primario dell'utente sotto forma di attestazione email. L'attestazione email è inclusa in un token solo se all'account utente è associato un indirizzo e-mail, cosa non sempre vera. Se usa l'ambito email, l'app deve essere preparata a gestire il caso in cui l'attestazione email non esiste nel token.

profile

L'ambito profile può essere usato con l'ambito openid e con tutti gli altri. Consente all'applicazione di accedere a numerose informazioni sull'utente, tra cui il nome e il cognome dell'utente, il nome utente preferito e l'ID oggetto. Per un elenco completo delle attestazioni profile disponibili nel parametro id_tokens per un determinato utente, vedere le informazioni di riferimento su id_tokens.

offline_access

L'ambito offline_access consente all'app di accedere alle risorse per conto dell'utente per un periodo di tempo prolungato. Nella pagina di consenso l'ambito viene visualizzato come autorizzazione "Mantieni l'accesso ai dati per cui hai concesso l'accesso a". Quando un utente approva l'ambito offline_access, l'app può ricevere i token di aggiornamento dall'endpoint di token Microsoft Identity Platform. I token di aggiornamento sono di lunga durata. L'applicazione può ottenere nuovi token di accesso quando i vecchi scadono.

In Microsoft Identity Platform (richieste effettuate all'endpoint v 2.0) l'app deve richiedere in modo esplicito l'ambito offline_access per ricevere i token di aggiornamento. Ciò significa che, quando si riscatta un codice di autorizzazione nel flusso del codice di autorizzazione OAuth 2.0, si riceve solo un token di accesso dall'endpoint /token. Il token di accesso è valido per un breve periodo di tempo e in genere scade in un'ora. A quel punto, l'app deve reindirizzare l'utente all'endpoint /authorize per recuperare un nuovo codice di autorizzazione. Durante il reindirizzamento, a seconda del tipo di app, l'utente potrebbe dover immettere nuovamente le proprie credenziali o fornire il consenso per le autorizzazioni.

Nota

Quando si usa un'applicazione a pagina singola, il token di aggiornamento viene sempre fornito.

Nota

Questa autorizzazione viene visualizzata in tutte le schermate di consenso, anche per i flussi che non forniscono un token di aggiornamento (flusso implicito). In questo modo vengono soddisfatte le esigenze di scenari in cui un client può iniziare all'interno del flusso implicito e quindi passare al flusso di codice dove è previsto un token di aggiornamento.

In una richiesta di autorizzazione OpenID Connect o OAuth 2.0, un'app può richiedere le autorizzazioni necessarie usando il parametro di query scope. Quando un utente accede a un'app, l'app invia una richiesta di autorizzazione. Il parametro scope è un elenco separato da spazi di autorizzazioni delegate richieste dall'app. Ogni autorizzazione è indicata dall'aggiunta del valore dell'autorizzazione all'identificatore della risorsa (URI dell'ID applicazione). Nella richiesta di esempio l'app necessita dell'autorizzazione delegata per la lettura del calendario dell'utente e l'invio di posta come utente.

Dopo che l'utente immette le proprie credenziali, l'endpoint Microsoft Identity Platform controlla se è presente un record corrispondente di consenso utente. Se l'utente non ha concesso 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, l'endpoint di Microsoft Identity Platform chiede all'utente di concedere le autorizzazioni richieste.

Nota

A questo punto, le autorizzazioni offline_access ("Conservazione dell'accesso ai dati per cui è stato autorizzato l'accesso") e user.read ("Accedi e visualizza il profilo personale") vengono incluse automaticamente nel consenso iniziale per un'applicazione. Queste autorizzazioni sono in genere necessarie per la corretta funzionalità dell'app. L'autorizzazione offline_access consente all'app di accedere ai token di aggiornamento, fondamentali per le app native e Web, mentre user.read concede l'accesso all'attestazione secondaria, che consente al client o all'app di identificare correttamente l'utente nel tempo e accedere a informazioni di base sull'utente.

Screenshot of the work account consent dialog. Users must agree to proceed with the application.

Quando l'utente approva la richiesta di autorizzazione, il consenso viene registrato e l'utente non deve fornirlo di nuovo agli accessi successivi all'applicazione.

Spesso, quando un'organizzazione acquista una licenza o una sottoscrizione per un'applicazione, vuole configurare in modo proattivo l'applicazione per l'uso da parte di tutti i membri dell'organizzazione. Come parte di questo processo, un amministratore può concedere il consenso all'applicazione ad agire per conto di qualsiasi utente nel tenant. Se l'amministratore concede il consenso per l'intero tenant, gli utenti dell'organizzazione non visualizzeranno la pagina di consenso per l'applicazione. Le applicazioni devono inoltre usare l'endpoint di consenso amministratore per richiedere le autorizzazioni delle applicazioni.