Demistificare OAuth 2.0 in Microsoft Graph: autorizzazioni delegate vs. autorizzazioni applicazione

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

Bentornato sul blog! Se ti stai immergendo a fondo nell'automazione di Microsoft 365, probabilmente ti sei già scontrato con i limiti imposti dai connettori nativi e dagli approcci tradizionali …

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

Bentornati sul blog! Se ti sei immerso a fondo nell'automazione di Microsoft 365, probabilmente ti sei già scontrato con i limiti imposti dai connettori nativi e dagli script tradizionali. Muoversi tra le complessità dell'autenticazione può essere complicato quando si automatizza Microsoft 365, soprattutto quando si cerca di bilanciare una sicurezza solida con una funzionalità senza attriti. Che tu stia creando applicazioni aziendali personalizzate o configurando processi automatizzati in background, avere una chiara comprensione dei modelli di autenticazione è fondamentale. Questo post analizza token, ambiti e flussi di consenso per aiutarti a scegliere il modello giusto, sia per i processi centrati sull'utente sia per le attività in background senza presidio. Iniziamo subito e vediamo come OAuth 2.0 alimenta l'API di Microsoft Graph.

Introduzione all'autenticazione di Microsoft Graph

Microsoft Graph è il gateway unificato per l'intero ecosistema di Microsoft 365. Invece di interagire con API separate e frammentate per Exchange, SharePoint, Teams e Azure Active Directory (ora Microsoft Entra ID), sviluppatori e amministratori IT possono accedere a tutti questi servizi tramite un unico endpoint. Tuttavia, poiché Graph controlla l'accesso a dati aziendali sensibili, proteggere questo gateway richiede un framework di autenticazione rigoroso. Comprendere come identità, token di accesso e autorizzazioni si intrecciano è il primo passo per costruire automazioni affidabili e sicure, che non si rompano sotto pressione o non attivino segnalazioni di sicurezza.

Comprendere OAuth 2.0 nel contesto di Microsoft 365

Alla base, Microsoft Graph si affida al protocollo OAuth 2.0 per l'autorizzazione. Quando la tua applicazione o il tuo script vuole comunicare con Graph, non può semplicemente inviare le credenziali in chiaro. Deve invece richiedere un token di accesso alla piattaforma di identità Microsoft (Entra ID). Questo token di accesso funziona come un passaporto digitale sicuro. Indica a Microsoft Graph chi sta effettuando la richiesta, quale applicazione viene utilizzata e, soprattutto, quali autorizzazioni specifiche (ambiti) sono state concesse a quel token. Senza un token valido, Graph rifiuterà immediatamente la richiesta con un errore standard di non autorizzato.

Autorizzazioni delegate: quando eseguire come utente

La scelta del modello di autorizzazione giusto dipende interamente dalla natura del tuo carico di lavoro. Le autorizzazioni delegate sono pensate per le app che operano con il supporto di un utente che ha effettuato l'accesso. Quando un'applicazione usa autorizzazioni delegate, agisce per conto dell'utente che è attualmente connesso. Se un utente esegue uno script per leggere il proprio calendario o aggiornare la foto del profilo, Graph valuta la richiesta non solo in base a ciò che l'applicazione è autorizzata a fare, ma anche in base a ciò che il singolo utente è autorizzato ad accedere. Se l'utente non ha l'autorizzazione per visualizzare una specifica casella di posta, anche il token delegato non la concederà. Questo modello è ideale per applicazioni rivolte agli utenti, strumenti interattivi e script di produttività personale.

Autorizzazioni applicazione: processi in background senza presidio

Al contrario, cosa succede quando è necessario eseguire uno script o un servizio a mezzanotte, senza alcun utente davanti alla tastiera? Per i processi in background senza presidio, i servizi daemon e gli strumenti di reporting a livello di tenant, servono le autorizzazioni applicazione. In questo modello, l'applicazione opera indipendentemente da qualsiasi contesto utente: viene eseguita con una propria identità. Poiché non esiste un utente che possa effettuare l'accesso e concedere il consenso in modo interattivo, le autorizzazioni applicazione richiedono una pre-autorizzazione esplicita da parte di un amministratore del tenant. Una volta concesse, l'app può accedere ai dati di tutta l'organizzazione, rendendo questo modello eccezionalmente potente per l'automazione amministrativa, gli script di onboarding e il monitoraggio della conformità, ma richiedendo anche una supervisione di sicurezza rigorosa.

Ambiti, token e flussi di consenso

Il vocabolario di autenticazione e autorizzazione può sembrare complicato, ma scomporre il flusso aiuta a capire il processo. Gli scope sono le autorizzazioni specifiche che la tua applicazione richiede, come User.Read.All o Mail.Read. Quando un utente o un amministratore autorizza un'app, sta esaminando e approvando questi scope. Una volta approvati, la piattaforma di identità emette un JSON Web Token (JWT). Il tuo codice include questo token nell'intestazione HTTP Authorization di ogni richiesta inviata a Microsoft Graph. Gestire correttamente il consenso fa sì che la tua app possa ottenere questi token senza intoppi e senza incontrare ostacoli imprevisti.

Evitare il purgatorio del consenso amministratore

Uno dei punti di attrito più comuni per sviluppatori e amministratori è restare bloccati in attesa dell'approvazione amministrativa. Quando un'applicazione richiede scope di application ad alto privilegio o scope delegati sensibili, Microsoft Entra ID può richiedere che un amministratore dia il consenso all'applicazione prima che possa essere emesso qualsiasi token. Se la tua pipeline di distribuzione presuppone che gli utenti possano concedere il consenso da soli e questi vengono improvvisamente bloccati dai criteri del tenant, l'automazione si arresta completamente. Per evitare il purgatorio del consenso amministratore, mappa sempre in anticipo le autorizzazioni richieste, documenta la giustificazione aziendale e coordinati con gli amministratori globali o delle applicazioni per preconfigurare, dove necessario, il consenso a livello di tenant.

Errori comuni e come risolverli

Anche gli sviluppatori esperti incontrano occasionalmente frustranti ostacoli di autorizzazione quando lavorano con Microsoft Graph. Vediamo alcuni problemi comuni e come risolverli:

• Funziona per me, non per gli altri: di solito è causato da consenso mancante o scope errati. Soluzione: documenta chiaramente gli scope richiesti e configura il consenso amministratore a livello di tenant, dove opportuno.
• Overfetching di payload enormi: recuperare interi elenchi di utenti senza filtri porta a timeout e throttling. Soluzione: usa $select, $top, la paginazione e le query delta.
• Cicli infiniti di 401/403: causati da un token scaduto o dall'uso di un tipo di autorizzazione delegata per un processo senza utente. Soluzione: implementa un meccanismo solido di aggiornamento dei token e passa alle autorizzazioni di application per le attività in background.
• Raggiungimento dei limiti di frequenza: ricevere risposte 429 significa che stai inviando richieste troppo velocemente. Soluzione: implementa il backoff esponenziale, rispetta l'intestazione Retry-After e raggruppa le operazioni in batch.
• Proliferazione dei segreti: inserire client secret in modo fisso negli script è un enorme rischio per la sicurezza. Soluzione: usa Azure Key Vault, identità gestite o variabili d'ambiente protette.

Best practice di sicurezza e governance

Quando apri la porta del tuo tenant di Microsoft 365 tramite API, la sicurezza deve essere la tua priorità assoluta. Seguire il principio del privilegio minimo significa richiedere solo gli scope strettamente necessari al funzionamento della tua applicazione: non richiedere mai Directory.AccessAsUser.All solo per leggere il nome visualizzato di un utente. Mantieni un registro chiaro del consenso che indichi quali app hanno accesso al tuo tenant, isola completamente le registrazioni delle applicazioni di sviluppo, test e produzione e stabilisci una pianificazione rigorosa per la rotazione dei client secret e dei certificati.

Le tue prime query reali (esempi)

Una volta sistemato il modello di autenticazione, puoi iniziare a eseguire query sulle API di Graph. Ecco alcuni esempi pratici che puoi adattare:

• Nuovi assunti da una certa data:
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• Le mie prossime riunioni:
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• Membri del team di un gruppo:
  GET /groups/{group-id}/members?$select=id,displayName,mail
• Utenti modificati (delta):
  GET /users/delta?$select=id,displayName,mail

Strumenti consigliati

Usare gli strumenti giusti rende molto più semplice creare e fare debug delle query di Microsoft Graph. Graph Explorer è un ambiente web indispensabile per testare gli endpoint e verificare i suggerimenti sul consenso. Per scrivere codice, gli SDK di Microsoft Graph (.NET, JavaScript, Python) astraggono gran parte della logica HTTP sottostante. Postman o le estensioni REST Client dell'IDE sono ottimi per gestire collezioni e ambienti, mentre Power Automate, Logic Apps e PowerShell si occupano in modo eccellente dell'automazione dei flussi visuali e operativi.

Domande frequenti

Delegated o Application: come scelgo?

Le attività centrate sull'utente si adattano meglio alle autorizzazioni delegate. Per i processi non presidiati, i daemon in background e le attività amministrative ampie servono invece autorizzazioni applicative, insieme al relativo consenso dell'amministratore.

Come si evita il throttling?

Usa $select per limitare la dimensione dei payload, implementa la paginazione e le query delta, raggruppa le richieste in batch quando possibile e fai sempre in modo che gli script gestiscano correttamente i codici di stato 429, con una logica di nuovo tentativo.

Posso usare Graph senza scrivere codice?

Sì! Puoi prototipare gli endpoint in Graph Explorer e orchestrare i flussi di lavoro con Power Automate. Per la logica più complessa, passa a usare gli SDK ufficiali o gli script PowerShell.

Graph è sufficientemente sicuro per i report di conformità?

Assolutamente sì. Se implementato con il principio del privilegio minimo, registrazione centralizzata, flussi di consenso sottoposti a audit e una gestione sicura dei segreti, Microsoft Graph soddisfa i rigorosi standard di conformità aziendali.

Conclusione

Padroneggiare l'autenticazione in Microsoft Graph è la chiave definitiva per qualsiasi amministratore, architetto o sviluppatore che voglia sfruttare appieno la potenza di Microsoft 365. Comprendendo la distinzione fondamentale tra autorizzazioni delegate e applicative, gestendo con attenzione ambiti e token e seguendo rigorosi criteri di governance della sicurezza, puoi creare automazioni potenti e sicure. Per approfondire ulteriormente l'argomento, esplorare gli esempi di codice e scoprire strategie avanzate per la gestione degli errori e il throttling, non perdere l'episodio di podcast correlato: Automate Microsoft 365 with Microsoft Graph API. Buona automazione!