Condividi tramite

Panoramica su autorizzazioni e consenso in Microsoft Identity Platform

  • Articolo

In Microsoft Identity Platform la comprensione delle autorizzazioni e del consenso è fondamentale per lo sviluppo di applicazioni sicure che richiedono l'accesso alle risorse protette. Questo articolo offre una panoramica dei concetti e degli scenari fondamentali correlati alle autorizzazioni e al consenso, consentendo agli sviluppatori di applicazioni di richiedere le autorizzazioni necessarie da utenti e amministratori. Comprendendo questi concetti, è possibile assicurarsi che le applicazioni richiedano solo l'accesso di cui hanno bisogno, promuovendo l'attendibilità e la sicurezza.

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 il modo in cui l'applicazione accede 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 cliente. 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 concessi all'utente 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 su RBAC per le applicazioni, vedere RBAC 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 di accesso solo tramite app, vedere accesso solo tramite app.

L'uso esclusivo delle app impiega i ruoli dell'app al posto degli 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 appropriate per l'applicazione dell'applicazione di risorse a cui accede. 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 è in grado di accedere ad alcun elemento a cui l'utente connesso non è riuscito ad accedere.

Ad esempio, considera un'applicazione a cui viene concesso il permesso delegato Files.Read.All per conto dell'utente. L'applicazione è 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 è in grado di accedere ai dati a cui è associata l'autorizzazione.

Ad esempio, un'applicazione con l'autorizzazione per l'applicazione dell'API Microsoft Graph Files.Read.All può 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
Accesso al contesto 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 potrebbero visualizzare una richiesta di consenso includono:

  • Durante la revoca del consenso precedentemente concesso.
  • Quando l'applicazione è programmata per richiedere specificamente il consenso durante l'accesso.
  • Durante l'uso del consenso dinamico da parte dell'applicazione per chiedere nuove autorizzazioni secondo necessità durante l'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, consulta l'esperienza di consenso dell'applicazione .

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à 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. Un amministratore potrebbe essere necessario per 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.

Preautorizzazione

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 pre-autorizzata non chiede 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 come 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 potrebbero concedere l'accesso alle informazioni riservate. Esempi di vari sistemi di autorizzazione in Microsoft includono ruoli predefiniti di Microsoft Entra, controllo degli accessi in base al ruolo di Azure, Controllo degli accessi in base al ruolo di Exchangee consenso specifico delle risorse di Teams.

Vedi anche