Introduzione alle autorizzazioni e al consenso

Per accedere a una risorsa protetta, ad esempio i dati di posta elettronica o di calendario, l'applicazione necessita dell'autorizzazione del proprietario della risorsa. Il proprietario della risorsa può consentire 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, dagli utenti e dagli 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 un accesso solo app, fungendo solo da identità dell'applicazione.

L'immagine mostra l'illustrazione degli 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 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 essere definite anche 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 potrebbe essere autorizzato ad accedere alle risorse directory da Azure Active Directory (Azure AD) controllo degli accessi in base al ruolo o accedere alle risorse di posta elettronica e calendario Exchange Online controllo degli accessi in base al ruolo. 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 l'accesso dell'utente. L'accesso alle applicazioni viene usato negli scenari, ad esempio automazione e 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 inclusi nell'ambito di un singolo utente.

L'accesso solo all'app usa i ruoli dell'app anziché gli ambiti delegati. Quando concesso tramite il consenso, i ruoli dell'app possono essere chiamati anche autorizzazioni per le applicazioni. Per l'accesso solo alle app, l'app client deve essere concessa ai ruoli app appropriati dell'app per le risorse che chiama per 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 nulla che l'utente connesso non possa accedere.

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

Le autorizzazioni dell'applicazione, talvolta denominate ruoli app vengono usate nello scenario di accesso solo app, senza un utente connesso presente. L'applicazione sarà in grado di accedere a tutti i dati associati all'autorizzazione. Ad esempio, un'applicazione concessa all'autorizzazione dell'applicazione Files.Read.All sarà in grado di leggere qualsiasi file nel tenant. Solo un amministratore o un proprietario dell'entità servizio può consentire le autorizzazioni dell'applicazione.

Esistono altri modi in cui le applicazioni possono essere concesse l'autorizzazione per l'accesso solo all'app. Ad esempio, un'applicazione può essere assegnata a un ruolo di controllo degli accessi in base al ruolo di Azure AD.

Confronto tra le autorizzazioni delegate e dell'applicazione

Autorizzazioni delegate Autorizzazioni dell'applicazione
Tipi di app Web/Mobile/App 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 consenso per i propri dati
- Gli amministratori possono consenso per tutti gli utenti
Solo l'amministratore può fornire il consenso
Metodi di consenso - Statico: elenco configurato nella registrazione dell'app
- Dinamica: 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 le 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 che l'app richiede tramite una richiesta di consenso. Altri scenari in cui gli utenti possono visualizzare una richiesta di consenso includono:

  • Quando è stato concesso in precedenza il consenso viene revocato.
  • Quando l'applicazione viene codificata per richiedere specificamente il consenso durante ogni 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 necessarie per l'applicazione e le informazioni sul server di pubblicazione. Per altre informazioni sul prompt dei consenso e sull'esperienza di consenso per amministratori e 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. Queste credenziali 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, l'utente viene visualizzato un prompt di consenso e viene chiesto di concedere all'applicazione le autorizzazioni richieste. In molti casi, un amministratore può essere richiesto per concedere il consenso per conto dell'utente.

A seconda delle autorizzazioni necessarie, alcune applicazioni potrebbero richiedere a un amministratore di essere l'utente che concede il consenso. Ad esempio, le autorizzazioni dell'applicazione e molte autorizzazioni delegate con privilegi elevati possono essere consentite solo da un amministratore. Gli amministratori possono concedere il consenso per se stessi o per l'intera organizzazione. Per altre informazioni sul consenso utente e amministratore, vedere Panoramica del consenso utente e amministratore.

Preautenticazione

La preauthorizzazione consente a un proprietario dell'applicazione di risorse di concedere le 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 concedere il consenso alle autorizzazioni. I proprietari delle risorse possono preauthorizzare le app client nel portale di Azure o usando PowerShell e LE API, ad esempio Microsoft Graph.

Passaggi successivi