Autorizzazioni delegate e autorizzazioni dell'applicazione in Microsoft Entra ID: cosa devono sapere gli amministratori

By Mirko Peters · 2026-10-28

Scopri le differenze fondamentali tra autorizzazioni delegate e autorizzazioni dell'applicazione in Microsoft Entra ID, con le best practice di sicurezza e le regole del privilegio minimo.

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

Quando si integrano strumenti di terze parti o applicazioni personalizzate nel proprio ambiente Microsoft 365, comprendere la differenza tra autorizzazioni delegate e autorizzazioni dell'applicazione è fondamentale per proteggere il cloud, prevenire la fuga di dati e applicare il principio del privilegio minimo in Microsoft Entra ID.

Punti chiave

• Le autorizzazioni delegate richiedono un utente con accesso effettuato e agiscono per suo conto, quindi l'app può accedere solo ai dati che l'utente è autorizzato a vedere.
• Le autorizzazioni dell'applicazione operano senza un utente, concedendo un accesso ampio a tutto il tenant e richiedendo l'approvazione di un amministratore.
• Il principio del privilegio minimo stabilisce che alle app vada sempre concesso il minimo insieme di autorizzazioni necessario per svolgere il proprio compito.
• Microsoft Graph funge da punto di accesso unificato ai dati di Microsoft 365, basandosi in larga misura su questi modelli di autorizzazione.
• Comprendere la differenza evita gravi lacune di sicurezza, come concedere accidentalmente un accesso a tutto il tenant alle applicazioni di terze parti.

Comprendere le autorizzazioni OAuth nel cloud Microsoft

Quando colleghi uno strumento di produttività esterno o uno script di automazione interno al tuo ambiente Microsoft 365, avvii un flusso OAuth 2.0 sottostante. Tuttavia, ottenere un token di accesso è solo metà della battaglia. Il vero confine di sicurezza è definito da ciò che quel token è effettivamente autorizzato a fare. Nell'ecosistema di identità Microsoft, incentrato su Microsoft Entra ID (in precedenza Azure Active Directory), le autorizzazioni si dividono in due tipi fondamentalmente diversi: autorizzazioni delegate e autorizzazioni dell'applicazione.

Confondere questi due modelli è uno degli errori più comuni per amministratori IT, sviluppatori e utenti avanzati. Scegliere il tipo di autorizzazione sbagliato può esporre accidentalmente dati dell'intera azienda o compromettere del tutto il funzionamento dell'applicazione. Vediamo come funziona ciascun tipo, dove si trovano e come gestirli correttamente.

Autorizzazioni delegate: agire per conto di un utente

Le autorizzazioni delegate sono pensate per le app con un utente reale davanti. Quando accedi a un'app mobile o a un servizio web con il tuo account Microsoft, l'app prende in prestito la tua identità per un insieme specifico di attività. Si parla in questo caso di autorizzazione delegata.

In questo scenario, l'app agisce come te. Può accedere solo ai dati a cui hai già il permesso di accedere, e nient'altro. Se il tuo account utente non ha accesso in lettura a una specifica cartella di SharePoint o al calendario di un collega, anche l'app non potrà accedervi. Poiché il raggio d'azione è naturalmente limitato dalle autorizzazioni del singolo utente, Microsoft consiglia di usare le autorizzazioni delegate ogni volta che nel flusso di lavoro è coinvolta una persona.

Come appaiono le autorizzazioni delegate in pratica

Interagisci con le autorizzazioni delegate ogni volta che clicchi su una richiesta di consenso. Un assistente per la pianificazione potrebbe mostrare una schermata che indica che vuole leggere il tuo calendario. Quella richiesta rappresenta un ambito OAuth specifico. Poiché sei presente per approvare o negare la richiesta, agisci come proprietario della risorsa e controlli esattamente ciò che l'applicazione client può prendere in prestito dal tuo profilo.

Autorizzazioni dell'applicazione: servizi in background e accesso a tutto il tenant

Le autorizzazioni dell'applicazione funzionano secondo un paradigma completamente diverso. Sono pensate per daemon in background, script di sincronizzazione automatizzati e servizi backend che girano alle tre di notte, quando nessun utente è connesso. Pensa a uno strumento di reporting automatico che aggrega i dati di ogni casella di posta dell'organizzazione.

Poiché non c'è un utente presente a fornire il contesto di identità, l'applicazione si autentica con le proprie credenziali (ad esempio un ID client e un segreto client tramite il flusso delle credenziali client). Di conseguenza, le autorizzazioni dell'applicazione danno allo strumento la capacità di agire per conto proprio in tutta l'organizzazione. Se un'app ha l'autorizzazione dell'applicazione per leggere la posta, può leggere la posta di ogni singolo utente del tenant.

Perché il consenso dell'amministratore è obbligatorio

Data l'enorme potenza associata alle autorizzazioni dell'applicazione, gli utenti normali non possono concederle. Mentre un dipendente standard può approvare un'autorizzazione delegata per il proprio calendario, le autorizzazioni dell'applicazione richiedono l'approvazione esplicita di un amministratore globale o di un amministratore di ruoli con privilegi. Questo controllo rigoroso impedisce che app dannose o scritte male raccolgano silenziosamente dati di tutta l'organizzazione.

Microsoft Graph e il ruolo degli ambiti OAuth

Che un'applicazione usi autorizzazioni delegate o dell'applicazione, alla fine indirizza le sue richieste attraverso un unico gateway potente: Microsoft Graph. Ogni chat di Teams, ogni documento di SharePoint, ogni file di OneDrive e ogni email di Outlook è raggiungibile tramite Microsoft Graph, purché l'applicazione chiamante presenti un token di accesso OAuth valido.

I vincoli che mantengono onesti questi token si chiamano ambiti (scope). Un ambito è un'etichetta precisa incorporata nel token che definisce con esattezza i limiti, ad esempio leggere un calendario piuttosto che inviare un'email. Quando gli sviluppatori richiedono ambiti troppo ampi (come chiedere l'accesso in lettura e scrittura quando basterebbe la sola lettura), violano i principi fondamentali della sicurezza. Gli amministratori devono verificare con attenzione questi ambiti durante le revisioni delle registrazioni delle app.

Applicare il principio del privilegio minimo nel tuo tenant

Le best practice di sicurezza in Microsoft Entra ID tornano sempre a un'unica regola d'oro: il principio del privilegio minimo. Ogni app, entità servizio e script di automazione deve ricevere il livello di accesso strettamente necessario per svolgere il proprio compito.

• Preferisci sempre le autorizzazioni delegate alle autorizzazioni dell'applicazione ogni volta che un utente interagisce con l'app.
• Controlla attentamente le richieste di consenso per assicurarti che le app non chiedano ambiti non necessari.
• Verifica regolarmente le applicazioni aziendali registrate in Microsoft Entra ID per revocare i token orfani o le registrazioni di app inutilizzate.
• Assicurati che esista una supervisione amministrativa per ogni flusso di credenziali client che opera in ambienti headless.

Conclusione

Comprendere i meccanismi dell'identità cloud moderna richiede di andare oltre i semplici pulsanti di accesso ed esaminare le strutture di autorizzazione sottostanti. Che tu gestisca app mobile rivolte agli utenti con ambiti delegati o pesanti automazioni aziendali basate su autorizzazioni dell'applicazione, comprendere questi confini è essenziale per un ambiente Microsoft 365 sicuro.

Per approfondire i fondamenti del funzionamento di questi scambi, ascolta l'episodio completo del podcast per una spiegazione senza gergo di OAuth 2.0, del ciclo di vita dei token e dei quattro attori di ogni scambio.

Domande frequenti

Gli utenti normali possono approvare le autorizzazioni dell'applicazione in Microsoft Entra ID?

No. Le autorizzazioni dell'applicazione funzionano senza un utente connesso e hanno una portata a livello di tenant. Pertanto, solo un amministratore con i diritti appropriati sul tenant può concederle.

Cosa succede se un utente tenta di accedere a un file tramite un'app con autorizzazioni delegate per cui non ha diritti?

Anche l'app verrà bloccata e non potrà accedere a quel file. Le autorizzazioni delegate prendono in prestito l'identità dell'utente, quindi l'app non può mai superare i limiti di accesso personali dell'utente.

Qual è il principale rischio per la sicurezza delle autorizzazioni dell'applicazione?

Poiché le autorizzazioni dell'applicazione eseguono servizi in background senza supervisione umana, una credenziale di app compromessa può concedere a un malintenzionato accesso illimitato alle caselle di posta, ai file e alle risorse di tutta l'azienda.

In che modo Microsoft Graph interagisce con i token OAuth e le autorizzazioni?

Microsoft Graph funge da gateway API per Microsoft 365. Ogni richiesta a Graph deve includere un token di accesso OAuth che incorpora ambiti specifici, i quali definiscono autorizzazioni delegate o autorizzazioni dell'applicazione.