Condividi tramite

Panoramica su autorizzazioni e consenso in Microsoft Identity Platform

  • Articolo

Per accedere a una risorsa protetta come i dati relativi a posta elettronica o calendario, l'applicazione richiede l'autorizzazione del proprietario della risorsa. Il proprietario della risorsa può autorizzare o negare la richiesta dell'app. La comprensione di questi concetti fondamentali consente di creare applicazioni più sicure e attendibili, in grado di richiedere agli utenti e agli amministratori solo l'accesso necessario e quando ne hanno bisogno.

Scenari di accesso

Gli sviluppatori di applicazioni devono identificare la modalità con cui l'applicazione accederà ai dati. L'applicazione può usare l'accesso delegato, che agisce per conto di un utente connesso, o l'accesso solo app, che funge solo da identità dell'applicazione.

Immagine che mostra gli scenari di accesso.

Accesso delegato (accesso per conto di un utente)

In questo scenario di accesso, un utente ha eseguito l'accesso a un'applicazione client. L'applicazione client accede alla risorsa per conto dell'utente. L'accesso delegato richiede autorizzazioni delegate. Sia il client che l'utente devono essere autorizzati separatamente a effettuare la richiesta. Per altre informazioni sullo scenario di accesso delegato, vedere Scenario di accesso delegato.

Per l'app client, è necessario concedere le autorizzazioni delegate corrette. Le autorizzazioni delegate possono anche essere definite ambiti. Gli ambiti sono autorizzazioni per una determinata risorsa che rappresentano ciò a cui un'applicazione client può accedere per conto dell'utente. Per altre informazioni sugli ambiti, vedere Ambiti e autorizzazioni.

Per l'utente, l'autorizzazione si basa sui privilegi che gli sono stati concessi per accedere alla risorsa. Ad esempio, l'utente può essere autorizzato ad accedere alle risorse della directory mediante il controllo degli accessi in base al ruolo di Microsoft Entra o ad accedere alle risorse di posta elettronica e calendario tramite il controllo degli accessi in base al ruolo di Exchange Online. Per altre informazioni sul controllo degli accessi in base al ruolo per le applicazioni, vedere Controllo degli accessi in base al ruolo per le applicazioni.

Accesso solo app (accesso senza utente)

In questo scenario di accesso, l'applicazione agisce autonomamente senza che l'utente abbia eseguito l'accesso. L'accesso alle applicazioni viene usato in scenari come l'automazione e il backup. Questo scenario include le app eseguite come servizi in background o daemon. È appropriato, nei casi in cui non sia consigliabile, avere un utente specifico connesso, oppure quando i dati necessari non possono essere limitati a un singolo utente. Per altre informazioni sullo scenario dell'accesso solo app, vedere Accesso solo app.

L'accesso solo app usa i ruoli dell'app anziché gli ambiti delegati. Se concessi tramite consenso, i ruoli dell’app possono essere anche denominati autorizzazioni delle applicazioni. All'app client devono essere concesse le autorizzazioni applicazione appropriate dell'app per le risorse che sta chiamando. Una volta concessa l'autorizzazione, l'app client può accedere ai dati richiesti. Per altre informazioni sull'assegnazione dei ruoli dell'app alle applicazioni client, vedere Assegnazione dei ruoli dell'app alle applicazioni.

Tipi di autorizzazioni

Le autorizzazioni delegate vengono usate nello scenario di accesso delegato. Sono autorizzazioni che consentono all'applicazione di agire per conto di un utente. L'applicazione non sarà mai in grado di accedere a qualsiasi elemento a cui l'utente connesso non sia riuscito ad accedere.

Si supponga, ad esempio, di avere un'applicazione a cui è stata concessa l'autorizzazione delegata Files.Read.All per conto dell'utente. L'applicazione sarà in grado di leggere solo i file a cui l'utente può accedere personalmente.

Le autorizzazioni dell'applicazione, denominate anche ruoli dell'app, vengono usate nello scenario di accesso solo app, ovvero senza un utente connesso. L'applicazione sarà in grado di accedere a tutti i dati a cui è associata l'autorizzazione.

Ad esempio, un'applicazione a cui è stata concessa l'autorizzazione dell'applicazione Files.Read.All dell'API Microsoft Graph sarà in grado di leggere qualsiasi file nel tenant usando Microsoft Graph. In generale, solo un amministratore o il proprietario dell'entità servizio di un'API può fornire il consenso alle autorizzazioni dell'applicazione esposte da tale API.

Confronto tra autorizzazione delegata e autorizzazione dell'applicazione

Tipi di autorizzazione Autorizzazioni delegate Autorizzazioni dell’applicazione
Tipi di app App Web/per dispositivi mobili/a pagina singola (SPA) Web/Daemon
Contesto di accesso Ottenere l'accesso per conto di un utente Ottenere l'accesso senza utente
Utenti che possono fornire il consenso - Gli utenti possono fornire il consenso per i propri dati
- Gli amministratori possono fornire il consenso per tutti gli utenti		 Solo l'amministratore può fornire il consenso
Metodi di consenso - Statico: elenco configurato nella registrazione dell'app
- Dinamico: richiedere singole autorizzazioni all'accesso		 - SOLO statico: elenco configurato nella registrazione dell'app
Altri nomi - Ambiti
- Ambiti di autorizzazione OAuth2		 - Ruoli dell'app
- Autorizzazioni solo app
Risultato del consenso (specifico per Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Un modo in cui vengono concesse le autorizzazioni alle applicazioni è il consenso. Il consenso è un processo in cui gli utenti o gli amministratori autorizzano un'applicazione ad accedere a una risorsa protetta. Ad esempio, quando un utente tenta di accedere a un'applicazione per la prima volta, l'applicazione può richiedere l'autorizzazione per visualizzare il profilo dell'utente e leggere il contenuto della sua cassetta postale. L'utente visualizza l'elenco delle autorizzazioni richieste dall'app tramite una richiesta di consenso. Altri scenari in cui gli utenti possono visualizzare una richiesta di consenso includono:

  • Durante la revoca del consenso precedentemente concesso.
  • Durante la codifica dell'applicazione, per chiedere in modo specifico il consenso al momento dell'accesso.
  • Durante l'uso del consenso dinamico da parte dell'applicazione, per richiedere nuove autorizzazioni in fase di esecuzione.

I dettagli chiave di una richiesta di consenso sono l'elenco delle autorizzazioni richieste dall'applicazione e le informazioni sull'entità di pubblicazione. Per altre informazioni sulla richiesta di consenso e sull'esperienza di consenso sia per gli amministratori che per gli utenti finali, vedere Esperienza di consenso per le applicazioni.

Quando tenta di accedere a un'applicazione, l'utente fornisce il suo consenso. L'utente fornisce le credenziali di accesso, che vengono controllate per determinare se il consenso è già stato concesso. Se non esiste alcun record precedente del consenso dell'utente o dell'amministratore per le autorizzazioni richieste, l'utente visualizza una richiesta di consenso e gli viene chiesto di concedere tali autorizzazioni all'applicazione. Può essere necessario chiedere a un amministratore di concedere il consenso per conto dell'utente.

A seconda delle autorizzazioni richieste, alcune applicazioni potrebbero richiedere che sia un amministratore a concedere il consenso. Ad esempio, le autorizzazioni dell'applicazione e molte autorizzazioni delegate con privilegi elevati possono essere concesse solo da un amministratore.

Gli amministratori possono concedere il consenso a se stessi o all'intera organizzazione. Per altre informazioni sul consenso dell'utente e dell'amministratore, vedere Panoramica del consenso utente e amministratore.

Le richieste di autenticazione vengono richieste per il consenso amministratore se il consenso non è stato concesso e se viene richiesta una di queste autorizzazioni con privilegi elevati.

Le richieste di autorizzazione che contengono ambiti applicazione personalizzati non sono considerate con privilegi elevati e pertanto non richiedono il consenso amministratore.

Pre-autorizzazione

La pre-autorizzazione consente al proprietario di un’applicazione della risorsa di concedere autorizzazioni senza richiedere agli utenti di visualizzare una richiesta di consenso per lo stesso set di autorizzazioni autorizzate. In questo modo, un'applicazione che è stata pre-autorizzata non chiederà agli utenti di acconsentire alle autorizzazioni. I proprietari delle risorse possono pre-autorizzare le app client nel portale di Azure o usando PowerShell e le API, ad esempio Microsoft Graph.

Altri sistemi di autorizzazione

Il framework di consenso è solo un modo in cui un'applicazione o un utente può essere autorizzato ad accedere alle risorse protette. Gli amministratori devono essere a conoscenza di altri sistemi di autorizzazione che possono concedere l'accesso alle informazioni riservate. Esempi di vari sistemi di autorizzazione in Microsoft includono i ruoli predefiniti Entra, il controllo degli accessi in base al ruolo di Azure, il controllo degli accessi in base al ruolo di Exchange e il consenso specifico delle risorse di Teams.

Vedi anche