Autorizzazioni delegate e applicazione: come scegliere il modello giusto per la tua app

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Bentornato al podcast e alla nostra serie che ti aiuta a padroneggiare Microsoft 365, Azure e gli strumenti per sviluppatori che alimentano l'ecosistema cloud moderno. Se hai mai creato un'integrazione, scritto uno script o distribuito un'automazione aziendale usando l'API Microsoft Graph, ti sarai sicuramente scontrato con il muro delle autorizzazioni. Proteggere il tuo tenant mentre sviluppi applicazioni funzionali è uno degli equilibri più critici che dovrai gestire come amministratore o sviluppatore. Scegliere tra i diversi modelli di autorizzazione influisce direttamente sulla tua postura di sicurezza, sulla velocità di distribuzione e sull'architettura complessiva del sistema.

Per approfondire questo argomento complesso, abbiamo registrato di recente un episodio di approfondimento. Non perdere la discussione audio completa su Microsoft Graph Permissions and Consent Models Explained. In questo articolo di approfondimento riprenderemo quei concetti, esamineremo le differenze principali tra autorizzazioni delegate e autorizzazioni applicazione, analizzeremo i modelli di consenso, esploreremo le migliori pratiche e forniremo un quadro completo per far sì che le tue app restino sicure e conformi.

Panoramica sulle autorizzazioni dell'API Microsoft Graph

Prima di entrare nel dettaglio dei singoli flussi di autorizzazione, è utile capire cosa sono davvero le autorizzazioni dell'API Microsoft Graph. In sostanza, Microsoft Graph funge da gateway unificato verso i dati presenti nei servizi di Microsoft 365, tra cui Exchange Online, SharePoint, Microsoft Teams, OneDrive e Azure Active Directory (Microsoft Entra ID). Invece di obbligare gli sviluppatori ad autenticarsi con più endpoint isolati, Microsoft Graph offre un unico endpoint REST. Tuttavia, poiché questa API dà accesso praticamente a ogni angolo del patrimonio digitale di un'organizzazione, proteggerla richiede un framework di autorizzazioni solido e granulare.

Autorizzazioni delegate e autorizzazioni applicazione

Quando registri un'applicazione nella piattaforma di identità Microsoft, devi dichiarare esplicitamente come la tua app intende interagire con le risorse. In sostanza, la scelta si riduce a due tipi principali di autorizzazioni: delegate e applicazione. Queste scelte determinano come l'applicazione si autentica, chi o cosa rappresenta e i limiti dei dati a cui può accedere.

Le autorizzazioni delegate sono pensate per applicazioni lato client o rivolte all'utente, come app web a pagina singola, app mobili o utilità desktop, in cui è presente attivamente un utente che ha effettuato l'accesso. In questo modello, la tua app opera *per conto* dell'utente. L'applicazione può accedere solo ai dati ed eseguire solo le azioni per cui l'utente stesso dispone dei diritti. Quando un utente avvia l'app, gli viene chiesto di accedere e concedere esplicitamente il consenso, e viene emesso un token di accesso OAuth 2.0 che contiene sia l'identità dell'utente sia gli ambiti approvati.

Le autorizzazioni applicazione, invece, sono utilizzate da servizi in background, daemon, web job e runbook automatizzati che operano indipendentemente da qualsiasi contesto utente. In questo caso, l'app agisce con una propria identità. Utilizza credenziali client, come un segreto client, una coppia di chiavi certificato pubblico/privato o un'identità gestita, per ottenere un token di accesso solo applicazione da Azure AD. Poiché nessun utente è davanti a una tastiera per autenticarsi, queste autorizzazioni si estendono alle risorse a livello di tenant. Di conseguenza comportano rischi per la sicurezza significativamente più elevati e richiedono sempre il consenso esplicito dell'amministratore del tenant.

Differenze principali e casi d'uso

Capire quando applicare ciascun modello di autorizzazione evita colli di bottiglia architetturali e vulnerabilità di sicurezza. Ecco una rapida analisi comparativa:

Autorizzazioni delegate: l'app lavora per conto di un utente. L'utente deve accedere e concedere il consenso. L'app può vedere solo ciò che vede l'utente. Questo modello è ideale per le app client che leggono o scrivono dati personali, come calendari o email individuali.
Autorizzazioni applicazione: l'app lavora come entità autonoma. Non serve che un utente acceda. Un amministratore deve concedere il consenso. L'app può visualizzare e modificare i dati dell'intero tenant. Questo modello è ideale per la sincronizzazione in background, la reportistica amministrativa e i processi automatizzati di governance.

La scelta del modello corretto dipende interamente dall'architettura della tua applicazione. Ad esempio, se stai creando una dashboard interattiva che mostra il profilo di un utente e la sua casella di posta personale, devi usare le autorizzazioni delegate. Al contrario, se stai sviluppando uno script automatizzato che a mezzanotte analizza tutte le caselle dell'organizzazione per un audit di conformità, sono necessarie le autorizzazioni di applicazione.

Autorizzazioni delegate in Microsoft Graph

Come funzionano le autorizzazioni delegate

L'accesso delegato è strettamente legato all'identità dell'utente. Quando la tua applicazione richiede un'autorizzazione delegata, chiede in sostanza al server di autorizzazione il permesso di impersonare l'utente che ha effettuato l'accesso, entro limiti definiti. Il token di accesso restituito tramite il flusso OAuth con codice di autorizzazione contiene specifiche attestazioni di ambito che riflettono sia i diritti intrinseci dell'utente sia le autorizzazioni richieste dall'applicazione.

Con l'accesso delegato, la tua app agisce direttamente come utente.
Sia la registrazione dell'applicazione sia il singolo utente devono disporre dei diritti sottostanti appropriati.
Gli ambiti definiscono il limite esatto di ciò che la tua app può fare per conto dell'utente.
Il token di accesso risultante associa insieme l'identità dell'applicazione e il contesto dell'utente.

Scenari comuni per le autorizzazioni delegate

Le autorizzazioni delegate alimentano la maggior parte delle integrazioni di produttività quotidiane. Ad esempio, se un'applicazione aziendale per la gestione di note deve sincronizzare file con il OneDrive di un utente, richiede l'ambito Files.ReadWrite. Se l'utente non dispone dell'autorizzazione per accedere a un determinato documento, l'API Graph rifiuterà la richiesta, anche se l'ambito dell'app lo consente sulla carta. Analogamente, le app che usano l'SDK di Microsoft Graph per inviare notifiche email automatiche per conto di un utente sfruttano ambiti delegati come Mail.Send.

Considerazioni su sicurezza e consenso

Sebbene le autorizzazioni delegate siano intrinsecamente più sicure delle autorizzazioni di applicazione a livello di tenant, perché sono vincolate dai limiti dell'utente, presentano comunque sfide di sicurezza specifiche. Se un'applicazione richiede ambiti troppo ampi, come l'accesso completo alla casella di posta e al profilo di directory di un utente, un attacco di phishing riuscito o la compromissione dell'app potrebbero esporre dati personali sensibili. Gli sviluppatori devono attenersi rigorosamente al principio del privilegio minimo, richiedendo solo gli ambiti strettamente necessari alla funzionalità immediata.

Autorizzazioni di applicazione in Microsoft Graph

Come funzionano le autorizzazioni di applicazione

Le autorizzazioni di applicazione eliminano del tutto l'elemento umano dal processo di autenticazione. Invece di interagire con una richiesta di accesso, l'applicazione si autentica direttamente con Microsoft Entra ID tramite credenziali client. Il token risultante contiene ruoli applicativi anziché ambiti delegati, concedendo all'entità di servizio un accesso ampio e non vincolato a tutte le risorse del tenant.

Le autorizzazioni di applicazione funzionano interamente senza un utente connesso.
L'applicazione ottiene un token solo applicazione per interrogare le risorse.
L'accesso è regolato dai ruoli applicativi assegnati all'entità di servizio, non dai privilegi del singolo utente.

Quando usare le autorizzazioni di applicazione

Limita rigorosamente le autorizzazioni di applicazione a carichi di lavoro back-end, daemon senza interazione e integrazioni tra sistemi. Esempi includono motori di provisioning automatico degli utenti, sistemi di backup centralizzati, strumenti di risposta agli incidenti di sicurezza e script di migrazione del tenant.

Consenso dell'amministratore e implicazioni di sicurezza

Poiché le autorizzazioni di applicazione aggirano i vincoli dei singoli utenti e concedono accesso a livello di tenant, gli utenti standard non possono concederle. Solo un amministratore con privilegi può fornire il consenso alle autorizzazioni di applicazione. Autorizzazioni di applicazione configurate in modo errato, come la concessione di Directory.ReadWrite.All o Mail.ReadWrite.All a un'app in background non attendibile o scritta male, possono esporre un intero tenant di Microsoft 365 a una compromissione totale. Controlla regolarmente le entità di servizio delle tue applicazioni aziendali.

Pro e contro delle autorizzazioni dell'API di Microsoft Graph

Pro

Modello di autorizzazione unificato: un framework di autorizzazione unico e coerente per tutti i servizi di Microsoft 365 semplifica l'amministrazione.
Ambiti granulari: gli ambiti delegati e di applicazione di dettaglio consentono architetture con privilegio minimo precise.
OAuth2/OpenID Connect standard: sfrutta protocolli di sicurezza standard del settore per un'integrazione dell'identità semplice.
Integrazione RBAC: si integra senza attriti con i ruoli di Azure AD e con i criteri di accesso condizionale, per una conformità centralizzata.
Consenso incrementale: consente alle app di richiedere autorizzazioni aggiuntive nel tempo, invece di chiederle tutte subito.

Svantaggi

Complessità: orientarsi tra ambiti delegati, ruoli dell'app e modelli di consenso dell'amministratore può sopraffare chi è alle prime armi.
Rischi legati ai privilegi elevati: configurare in modo errato autorizzazioni ampie (come Sites.FullControl.All) può esporre enormi quantità di dati aziendali.
Colli di bottiglia nel consenso dell'amministratore: richiedere l'approvazione amministrativa per autorizzazioni ad alto impatto può rallentare i cicli di sviluppo agile.
Documentazione frammentata: gli sviluppatori devono spesso consultare più repository della documentazione Microsoft per capire il comportamento esatto delle API.

Modelli di consenso e buone pratiche

Consenso utente e consenso amministratore in Microsoft Graph

Gestire come viene acquisito il consenso è fondamentale per la governance dell'organizzazione. Il consenso utente consente ai singoli di autorizzare le app ad accedere ai propri dati personali. Il consenso amministratore sposta il punto di approvazione agli amministratori IT, che valutano le richieste delle app per conto dell'intera organizzazione. Le moderne baseline di sicurezza aziendali spesso disattivano del tutto il consenso utente, obbligando a far passare ogni onboarding delle applicazioni da flussi di pre-approvazione amministrativa formalizzati.

Impatto dei criteri del tenant sulle autorizzazioni

I criteri del tenant aziendale possono modificare in modo sostanziale il comportamento della tua app in fase di esecuzione. Se un amministratore ha imposto criteri di accesso condizionale rigorosi, come l'autenticazione a più fattori (MFA) o dispositivi aggiunti ad Azure AD ibrido e conformi, un'applicazione che tenta di ottenere un token per Graph senza soddisfare tali requisiti verrà bloccata. Gli sviluppatori devono progettare le proprie applicazioni in modo da gestire con garbo i errori di acquisizione del token e fornire all'utente indicazioni chiare per risolvere il problema.

Strategie per un flusso di consenso senza intoppi

Per evitare attriti per gli utenti e blocchi amministrativi, pianifica la strategia delle autorizzazioni prima di scrivere il codice. Implementa modelli di consenso incrementale: la tua app richiede subito gli ambiti di identità di base e chiede autorizzazioni specifiche per le risorse solo quando l'utente accede a quelle funzionalità. Utilizza flussi di pre-approvazione automatizzati in Microsoft Entra ID per semplificare lo sviluppo, mantenendo al tempo stesso un controllo rigoroso sulla sicurezza.

Errori comuni relativi alle autorizzazioni di Microsoft Graph API

Confondere autorizzazioni delegate e autorizzazioni applicative, e non comprendere i requisiti del contesto utente.
Richiedere subito autorizzazioni eccessive invece di adottare un approccio con privilegi minimi.
Non considerare i requisiti di consenso amministratore durante la distribuzione di servizi in background.
Dare per scontato che le modifiche alle autorizzazioni nel portale di Azure abbiano effetto immediato, senza aggiornare il token.
Presentare un token di accesso delegato dove è richiesto un token con credenziali client.
Ignorare i criteri di accesso condizionale che bloccano le richieste a Graph API in fase di esecuzione.
Trascurare la convalida delle attestazioni di ambito all'interno del codice dell'applicazione in fase di esecuzione.
Non verificare nel tempo le autorizzazioni applicative concesse e le entità servizio.

Checklist delle autorizzazioni di Microsoft Graph API

Usa questa checklist operativa per guidare il tuo team nella progettazione, nell'implementazione e nel controllo delle autorizzazioni di Microsoft Graph API in modo sicuro:

Conclusione

Orientarsi tra le autorizzazioni di Microsoft Graph API non deve essere una fonte di frustrazione. Capendo con chiarezza le differenze operative tra autorizzazioni delegate (che richiedono un utente con accesso e operano entro i limiti dell'utente) e autorizzazioni applicative (che vengono eseguite senza vincoli in background e richiedono il consenso amministratore), puoi progettare soluzioni sicure e scalabili. Adottare il principio del privilegio minimo, applicare controlli rigorosi e sfruttare gli strumenti di governance aziendale terrà al sicuro il tuo ambiente Microsoft 365 senza rallentare l'innovazione.

Per approfondimenti pratici, strategie reali e analisi dettagliate sulla sicurezza del tuo ambiente cloud, non perdere la nostra analisi audio completa nell'episodio correlato: Microsoft Graph Permissions and Consent Models Explained. Mantieni le tue autorizzazioni strette, le tue credenziali al sicuro e buon coding!