Autorizzazioni delegate vs autorizzazioni applicative

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Confronta le autorizzazioni delegate e quelle applicative in Microsoft Entra ID e scegli il modello di accesso giusto per API sicure, automazione e sviluppo di app.

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

Quando lavori con Microsoft Entra ID, capire chi può fare cosa e in quali circostanze non è un dettaglio tecnico. È la base dello sviluppo di app sicure, dell'automazione e della gestione complessiva delle identità nel cloud di Microsoft. C'è una bella differenza tra consentire agli utenti di concedere solo l'accesso necessario affinché la tua app agisca per loro conto (autorizzazioni delegate) e dare a un'app le chiavi per agire in autonomia (autorizzazioni applicative).

Sbagliare significa rischiare esposizione indesiderata dei dati, grattacapi di conformità o persino incidenti di sicurezza. Farlo bene significa automazione più fluida, governance più chiara e auditor più soddisfatti. Questa guida ti offre il quadro completo: le basi di questi tipi di autorizzazione, come funzionano nella pratica e tutti gli aspetti di sicurezza, governance e operatività che ti servono per fare la scelta migliore per il tuo ambiente. Mettiamo le autorizzazioni al posto giusto, perché con il grande accesso arriva una grande responsabilità.

Introduzione e contesto sui modelli di autorizzazione in Microsoft Identity

Le autorizzazioni in Microsoft Entra ID non sono semplici caselle da spuntare: sono un sistema fondamentale integrato nel modo in cui app e utenti collaborano in Microsoft 365, Azure e non solo. Quando Microsoft ha spostato l'identità nel cloud, era necessario un modo per far interagire in sicurezza servizi e strumenti di terze parti, senza concedere accesso generalizzato a tutto e a tutti. Ed ecco le autorizzazioni delegate e applicative.

Questi modelli permettono di gestire con precisione chi può accedere a cosa, tracciando confini chiari tra ciò che un singolo utente può approvare e ciò che solo un amministratore dovrebbe consentire. Sono il risultato di anni di esperienza (a volte imparata a caro prezzo) con i classici account di servizio di AD e con l'accesso rigido, o tutto o niente. Comprendere questi modelli non è solo buona igiene informatica: è essenziale per rispettare la conformità, applicare Zero Trust e evitare che le operazioni quotidiane si blocchino per errori di configurazione della sicurezza.

Autorizzazioni applicative vs autorizzazioni delegate: concetti chiave e scenari reali

Vediamo in termini semplici la differenza tra autorizzazioni delegate e applicative. Pensa alle autorizzazioni delegate come a un'app che fa da assistente: ottiene l'accesso solo mentre un utente specifico è connesso, e si limita a ciò che quell'utente potrebbe fare. Le autorizzazioni applicative, invece, permettono all'app di agire in autonomia, come un manager senza supervisione con un proprio set di chiavi. Non ha bisogno che un utente sia presente.

Con le autorizzazioni delegate, l'autenticazione coinvolge sempre un utente. Quando qualcuno accede, ad esempio a un'app che deve leggere la sua posta o il suo calendario, concede all'app una finestra temporanea per operare con la propria autorità. Se l'utente esce, la finestra si chiude. È ideale per le app che lavorano su richiesta dell'utente, come i front-end web, i bot di Teams o le app mobili di produttività.

Con le autorizzazioni applicative, l'app si autentica con una propria identità (un'entità servizio) e ottiene un proprio token. È ciò che alimenta automazione e processi in background, come un'integrazione di sistema che sincronizza i dati tra SharePoint e il tuo CRM durante la notte. Non serve alcuna interazione con l'utente: l'app esegue le attività secondo la propria pianificazione e con il proprio livello di accesso, sempre entro i limiti approvati da un amministratore.

Immagina di dover automatizzare il provisioning degli utenti: un servizio in background che aggiorna silenziosamente gli account ogni notte. In questo caso le autorizzazioni delegate non servono, perché non c'è nessuno che possa approvare l'accesso. Ma quando la soluzione deve offrire funzionalità personalizzate mentre l'utente è attivo, come un'app per la firma di documenti collegata a OneDrive, allora le autorizzazioni delegate sono la scelta giusta.

Negli scenari reali spesso servono entrambe, quindi capire quale modello si adatta al tuo caso d'uso è fondamentale per l'esperienza utente, la governance e la sicurezza. Non vuoi distribuire più chiavi del necessario, ma non vuoi nemmeno che il servizio resti bloccato alle 3 di notte perché non c'è nessuno che accede.

Autorizzazioni delegate di Microsoft Entra: flusso di autenticazione e limiti

Le autorizzazioni delegate in Microsoft Entra ID seguono un classico flusso di autenticazione guidato dall'utente. Inizia quando un utente accede alla tua applicazione con le proprie credenziali Microsoft. A questo punto l'app richiede autorizzazioni specifiche, o ambiti, mostrando all'utente (e talvolta a un amministratore) esattamente quali dati o azioni intende utilizzare.

Se le autorizzazioni richieste prevedono solo il consenso dell'utente, questo le approva al volo tramite una schermata di consenso. Per le autorizzazioni più sensibili (come leggere la casella di posta di tutti nell'organizzazione), è richiesto il consenso dell'amministratore. Una volta concesso il consenso, l'app riceve un token di accesso legato direttamente all'identità dell'utente e ai ruoli assegnati.

Questo token di accesso consente all'app di chiamare Microsoft Graph o le API di Microsoft 365, ma agisce sempre con l'autorità dell'utente. Quindi, se l'utente è un dipendente standard, l'app non può improvvisamente ottenere funzionalità di amministrazione. Non appena l'utente effettua la disconnessione, l'accesso dell'app si interrompe, e così si limita il raggio d'azione in caso di problemi.

Ma ecco il limite: le autorizzazioni delegate non funzionano nei scenari senza presidio. Se stai eseguendo un processo in background, un job pianificato o un'integrazione di servizio che non dovrebbe dipendere dal fatto che qualcuno sia attivamente connesso, le autorizzazioni delegate non sono adatte. Legano tutto alla presenza dell'utente, il che significa che supporto, automazione e job notturni si scontrano con un muro.

C'è anche un aspetto di sicurezza da considerare. Se un utente con ampi privilegi viene indotto con l'inganno a concedere il consenso, un'app potrebbe abusare di tali autorizzazioni: è un vettore chiave negli attacchi di phishing del consenso. Per questo servono controlli rigorosi su chi può concedere quali autorizzazioni e una solida formazione di sensibilizzazione sul significato reale di quelle schermate di consenso.

Autorizzazioni eccessive per l'accesso delle app e sicurezza dei token in Microsoft Entra ID

Quando si parla di autorizzazioni, più non significa sempre meglio. Anzi, le autorizzazioni eccessive, ovvero l'assegnazione di privilegi non necessari o superiori al bisogno, soprattutto con le autorizzazioni di applicazione, possono spalancare la porta a fughe di dati sensibili e incidenti di sicurezza gravi. Immagina di concedere a un'app l'accesso in lettura e scrittura a tutte le caselle di posta dell'azienda, quando in realtà deve solo leggere gli eventi del calendario: così hai reso la superficie di attacco molto più ampia.

Questo pericolo non è solo teorico. Gli attaccanti stanno sfruttando l'abuso del consenso OAuth per aggirare anche l'autenticazione a più fattori. Prendono di mira utenti o amministratori con richieste di consenso ingegnose, inducendoli ad approvare autorizzazioni rischiose. Una volta dentro, queste app dannose spesso mantengono l'accesso anche se le password vengono modificate o se viene imposta l'MFA. La presa dell'attaccante persiste, rendendo inefficaci le difese tradizionali. Per un'analisi concreta, leggi questa spiegazione di come gli attaccanti abusano del consenso OAuth in Entra ID e i modi migliori per bloccarlo.

Il discorso non si limita alle autorizzazioni eccessive. Anche i token e le credenziali, compresi i segreti client e i certificati, possono diventare un bersaglio ambito se non vengono protetti. Un segreto client trapelato da una registrazione app-only è tutto ciò che serve a un attaccante per impersonare il tuo servizio. Per questo l'igiene delle credenziali è essenziale: usa le identità gestite quando possibile, ruota regolarmente i segreti e non memorizzare mai le credenziali client nel codice o in file non protetti. Per gli ambienti che dipendono da accessi non umani, valuta le identità dei carichi di lavoro di Microsoft Entra, che consentono un accesso senza segreti e verificabile ed eliminano i problemi degli account di servizio legacy. Qui trovi un approfondimento su perché le identità dei carichi di lavoro sono indispensabili per lo Zero Trust.

Infine, un monitoraggio adeguato non è negoziabile. Controlla regolarmente i log di accesso e le concessioni OAuth, imposta avvisi per consensi o utilizzi dei token sospetti e anticipa il phishing del consenso e il furto di token. I risultati di violazioni reali (come questa catena di attacco di Microsoft 365) mostrano che gli attaccanti sfruttano una governance debole, quindi più visibilità hai, meglio è. Proteggi le chiavi, restringi le autorizzazioni e mantieni le tue app oneste.

Controlli e procedure consigliate per la gestione delle autorizzazioni delegate e delle applicazioni

• Implementa i controlli integrati di Entra per la gestione delle autorizzazioniSfrutta i flussi di consenso integrati, i processi di approvazione dell'amministratore e i criteri granulari di Microsoft Entra per limitare gli utenti o i gruppi che possono concedere autorizzazioni. Usa i criteri di consenso dell'amministratore per assicurarti che solo le app verificate ricevano ambiti ad alto rischio.
• Applica il principio del privilegio minimoConcedi alle app solo il set minimo di autorizzazioni necessario per la loro funzione. Verifica ogni autorizzazione richiesta durante la registrazione dell'app ed elimina tutto ciò che non è necessario. Il privilegio minimo è la tua difesa più efficace contro abusi ed eccessi di accesso.
• Pianifica revisioni e audit periodici delle autorizzazioniConfigura revisioni regolari degli accessi, usando le dashboard di Entra per autorizzazioni e consensi, per individuare e revocare le autorizzazioni inutilizzate o rischiose. Automatizza questi controlli quando possibile per una governance scalabile, come illustrato in guide avanzate sulla governance come questa strategia di Microsoft Purview.
• Monitora le modifiche alle autorizzazioni e configura gli avvisiPredisponi il monitoraggio e gli avvisi per intercettare nuove concessioni OAuth, picchi nell'utilizzo delle autorizzazioni delle app o integrazioni amministrative inattese. La segnalazione proattiva ti dà il tempo di reagire prima che i problemi di sicurezza si aggravino.
• Proteggi l'archiviazione di token e credenzialiConserva i client secret e i token in vault sicuri come Azure Key Vault. Ruota le credenziali con regolarità, preferisci i certificati ai segreti condivisi e utilizza le identità dei carichi di lavoro per le integrazioni che richiedono accessi non umani, perché offrono una gestione del ciclo di vita e una verificabilità migliori.
• Adotta una governance avanzata e l'automazione dei criteriSfrutta strumenti come Microsoft Purview e Azure Policy per applicare controlli a livello di tenant, segmentare il rischio con Data Loss Prevention e progettare per una conformità continua. Per un esempio pratico di come usare i criteri per una governance by design, consulta la strategia di governance enterprise di Azure.

Seguendo questi passaggi e usando l'ecosistema di strumenti di governance di Microsoft, potrai aiutare la tua organizzazione a gestire i rischi legati alle autorizzazioni prima che diventino problemi. Istruisci regolarmente gli utenti sulle pratiche sicure di consenso, automatizza dove possibile e ricorda: la gestione delle autorizzazioni non è mai un'attività una tantum. Mantieni alta l'attenzione, continua a perfezionare i criteri e il tuo ambiente Entra ID resterà in buone condizioni.

Ascolta anche

Se stai esplorando autorizzazioni delegate e autorizzazioni applicative in Entra ID, questi episodi offrono un contesto pratico per un'adozione sicura di Microsoft 365, la protezione dei dati, la governance e la gestione dei rischi legati all'IA.

• Microsoft Purview – Simply Explained — Scopri come classificazione, conservazione, conformità e protezione si inseriscono in un unico modello di governance dei dati Microsoft.
• Microsoft Defender XDR – Simply Explained — Collega i controlli di protezione dei dati con rilevamento, indagine e risposta.
• Conditional Access – Simply Explained — Capisci come i segnali di identità e di rischio aggiungono contesto alle decisioni di accesso.
• Microsoft AI Agent Harness – Simply Explained — Esplora i controlli che rendono l'automazione basata sull'IA più affidabile, osservabile e sicura.

Questi episodi aiutano a trasformare i concetti dell'articolo in decisioni pratiche di progettazione e implementazione.