Panoramica delle autorizzazioni e del consenso in Microsoft Identity Platform

Per accedere a una risorsa protetta come posta elettronica o dati del calendario, l'applicazione necessita dell'autorizzazione del proprietario della risorsa. Il proprietario della risorsa può fornire il consenso o negare la richiesta dell'app. La comprensione di questi concetti fondamentali consente di creare applicazioni più sicure e affidabili che richiedono solo l'accesso necessario, quando necessario, da utenti e amministratori.

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 di accesso solo app, fungendo solo da identità dell'applicazione.

Image shows illustration of access scenarios.

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 per 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ò che 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 concessi dall'utente per accedere alla risorsa. Ad esempio, l'utente può essere autorizzato ad accedere alle risorse della directory dal controllo degli accessi in base al ruolo di Microsoft Entra o per 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 un utente)

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

L'accesso solo app usa i ruoli dell'app anziché gli ambiti delegati. Quando viene concesso tramite il consenso, i ruoli dell'app possono anche essere chiamati autorizzazioni per le applicazioni. All'app client devono essere concesse le autorizzazioni dell'applicazione appropriate dell'app per le risorse che sta chiamando. Una volta concessa, 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 è riuscito ad accedere.

Ad esempio, accettare un'applicazione a cui è stata concessa l'autorizzazione Files.Read.All delegata 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, note anche come ruoli dell'app, vengono usate nello scenario di accesso solo app, senza che sia presente un utente connesso. L'applicazione sarà in grado di accedere ai dati a cui è associata l'autorizzazione.

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

Confronto delle autorizzazioni delegate e dell'applicazione

Tipi di autorizzazione Autorizzazioni delegate Autorizzazioni dell'applicazione
Tipi di app App Web/Mobile/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
- Amministrazione può 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'account di 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 le applicazioni vengono concesse autorizzazioni è tramite 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 cassetta postale dell'utente. 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:

  • Quando viene revocato il consenso precedentemente concesso.
  • Quando l'applicazione viene codificata per richiedere in modo specifico il consenso durante l'accesso.
  • Quando l'applicazione usa il consenso dinamico 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'editore. 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 dell'applicazione.

Il consenso dell'utente si verifica quando un utente tenta di accedere a un'applicazione. L'utente fornisce le credenziali di accesso, che vengono controllate per determinare se il consenso è già stato concesso. Se non esiste alcun record precedente di consenso utente o amministratore per le autorizzazioni necessarie, all'utente viene visualizzata una richiesta di consenso e viene chiesto di concedere all'applicazione le autorizzazioni richieste. Un amministratore può essere necessario per concedere il consenso per conto dell'utente.

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

Amministrazione istrator possono concedere il consenso per se stessi o per l'intera organizzazione. Per altre informazioni sul consenso dell'utente e dell'amministratore, vedere Panoramica del consenso dell'utente e dell'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 dell'amministratore.

Preautenticazione

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

Vedi anche