Guida alla registrazione delle app e a OAuth per l'integrazione sicura delle applicazioni

By Mirko Peters · 2026-05-04

Registra la tua app con OAuth 2.0. Scopri il flusso con codice di autorizzazione per un accesso sicuro, una parte fondamentale del grant type authorization code di OAuth 2.0.

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

Ammettiamolo: far funzionare bene l'autenticazione e la registrazione delle app non significa solo seguire protocolli complicati; significa assicurarsi che utenti, dati e organizzazione restino al sicuro. Questa guida chiarisce la registrazione delle app e OAuth 2.0, così puoi creare un'autenticazione sicura e basata su standard con Microsoft Entra ID (ex Azure AD) o con il provider che preferisci.

Vedremo i passaggi e i concetti che ti servono, dal perché di OAuth fino a metterci mano concretamente, che si tratti di app web, mobile o SaaS. Lungo il percorso troverai definizioni chiare, consigli pratici e una tabella di marcia pensata per mantenere l'integrazione sulla giusta strada ed evitare i passi falsi tipici di chi si avvicina a OAuth. Che tu stia esplorando l'argomento per la prima volta o stia ottimizzando una configurazione enterprise avanzata, sei nel posto giusto per costruire con sicurezza e capire gli identificativi necessari alla tua applicazione.

Guida alla registrazione delle app e a OAuth — Definizione

La registrazione di un'app è il processo di creazione e configurazione di un'identità applicativa presso un provider di identità (come Azure AD, Google o Auth0), così che l'applicazione possa richiedere in modo sicuro autenticazione e autorizzazione. Di solito comporta l'assegnazione di un client ID, di un client secret o di un certificato, la definizione degli URI di reindirizzamento, l'impostazione di autorizzazioni e scope e la configurazione dei grant type consentiti.

8 fatti sorprendenti su registrazione delle app e guida a OAuth

• I client secret possono finire nei log: molti sviluppatori registrano involontariamente client ID e secret durante il debug, rendendo vulnerabili le credenziali dell'app se le policy di logging non vengono rafforzate. Tratta sempre questi identificativi con la massima cura.
• Gli URI di reindirizzamento sono più rigidi di quanto ti aspetti: i provider OAuth richiedono spesso una corrispondenza esatta degli URI di reindirizzamento (incluse le barre finali e lo schema), quindi differenze minime possono interrompere flussi che sembrano configurati correttamente nella registrazione dell'app.
• I client pubblici non richiedono secret, ma vanno comunque protetti: le app native e le single-page app sono trattate come client pubblici senza client secret, ma devono comunque usare PKCE e approcci di reindirizzamento sicuri per impedire l'intercettazione del codice.
• Gli scope non garantiscono il privilegio minimo per impostazione predefinita: durante la registrazione delle app, gli scope predefiniti o le schermate di consenso possono richiedere autorizzazioni ampie; limitare esplicitamente gli scope e chiedere il consenso in modo incrementale è essenziale per applicare il principio del privilegio minimo.
• La revoca dei token non è supportata ovunque: non tutti i provider di identità rispettano la revoca dei token o offrono il logout immediato su tutte le sessioni, quindi la registrazione dell'app deve includere la gestione delle sessioni e le policy dei refresh token.
• I metadati della registrazione dell'app sono una superficie di attacco: nomi, logo e URI di reindirizzamento pubblicamente esposti possono aiutare gli attaccanti a costruire phishing convincenti o attacchi di open redirect se non vengono gestiti con attenzione.
• Il provisioning automatizzato può configurare male le autorizzazioni: le automazioni CI/CD che creano registrazioni di app spesso concedono autorizzazioni API eccessive oppure non registrano gli URI di reindirizzamento necessari, causando errori silenziosi o esposizioni di sicurezza.
• L'esperienza di consenso influisce sulle decisioni di sicurezza: utenti e amministratori concedono spesso ampi consensi perché le finestre di dialogo sono confuse; progettare richieste di consenso chiare e minime nella registrazione dell'app e nella guida a OAuth riduce la concessione eccessiva di accessi.

Capire OAuth 2.0 e i fondamentali di Entra ID

OAuth 2.0 è la base dei moderni flussi di autenticazione: permette alle app di accedere in modo sicuro ai dati e alle risorse degli utenti senza mai vedere una password. Ecco una panoramica del processo OAuth. Al suo centro, OAuth 2.0 definisce come un utente (il « proprietario della risorsa »), un'app (il « client») e un identity provider (il « server di autorizzazione ») collaborano, in modo che gli utenti mantengano il controllo sulle proprie informazioni.

Ma cosa succede quando vuoi autenticare gli utenti, e non solo autorizzare l'accesso ai dati? È qui che entra in gioco OpenID Connect, che aggiunge identità e accesso sicuri sopra OAuth 2.0. Con OpenID Connect, provider come Microsoft Entra ID e Google permettono alle tue app di verificare chi sono gli utenti e di richiedere autorizzazioni con ambito limitato per altre risorse, in un'unica esperienza integrata.

Se senti parlare di « client ID », « endpoint di autorizzazione » o « access token », non lasciarti sopraffare. Tutti questi concetti si riconducono a un'unica domanda: chi sta parlando con chi, e cosa gli è permesso fare. Microsoft Entra ID, in particolare, usa questi protocolli per offrire agli sviluppatori una base standard, adatta a qualsiasi scenario, dalle app aziendali single-tenant alle grandi soluzioni SaaS multi-tenant.

Conoscere questi fondamenti significa costruire su basi solide. Scegliere il flusso OAuth giusto per il tuo scenario (ad esempio il code flow per le web app o il device flow per gli smart TV) garantisce un accesso sicuro e lineare, di cui gli utenti possono fidarsi e che il tuo team di compliance apprezzerà.

Guida alla registrazione delle app e a OAuth: gli errori più comuni con OAuth 2.0 ed Entra ID

Questa guida alla registrazione delle app e a OAuth elenca gli errori frequenti che i team commettono quando implementano OAuth 2.0 con Microsoft Entra ID (Azure AD) e il loro impatto su sicurezza, funzionalità ed esperienza utente.

• Mescolare concetti di OAuth 2.0 e OpenID Connect (ad esempio aspettarsi gli ID token dove vengono emessi solo access token).
• Usare in modo errato i flussi OAuth: considerare il flusso implicito adatto alle app moderne invece dell'Authorization Code con PKCE.

• Registrare in modo errato i redirect URI (schema sbagliato, barra finale o uso di localhost in produzione).
• Usare impostazioni da client pubblico per app riservate o viceversa, con conseguenti errori di token o segreti esposti.
• Non impostare le autorizzazioni API o gli ambiti corretti, oppure dimenticare di concedere il consenso dell'amministratore dove richiesto.

• Inserire i segreti client nel codice lato client o in repository pubblici.
• Non ruotare regolarmente segreti e certificati, o non rimuovere le credenziali scadute dalla registrazione dell'app.
• Usare segreti a lunga durata senza necessità, invece di certificati a breve durata o identità gestite.

• Non validare correttamente i token (issuer, audience, firma, nonce, exp).
• Archiviare access token o refresh token in modo non sicuro (ad esempio nell'archivio locale del browser senza protezione).
• Fidarsi del contenuto dei token senza verificare gli ambiti o i ruoli restituiti da Entra ID.

• Supporre che il consenso dell'utente equivalga all'autorizzazione dell'app, senza considerare che alcune autorizzazioni richiedono il consenso dell'amministratore.
• Richiedere autorizzazioni o ambiti eccessivi, con rischi inutili e un tasso più alto di rifiuti durante il consenso.

• Non gestire la rotazione e i criteri di revoca dei refresh token di Entra ID, con disconnessioni impreviste.
• Usare i refresh token nei client pubblici senza adeguate protezioni (usa PKCE e durate dei token appropriate).

• Non configurare correttamente le impostazioni multi-tenant per le app destinate a funzionare su più tenant.
• Usare endpoint errati (specifici del tenant o common) e riscontrare problemi di accesso o di consenso.

• Non testare il comportamento dell'app quando sono applicati l'Accesso condizionale, MFA o i criteri di conformità dei dispositivi.
• Dare per scontato che i token verranno sempre emessi nelle stesse condizioni: i criteri possono bloccarli o richiedere ulteriori passaggi di autenticazione.

• Seguire flussi OAuth legacy o schemi di Azure AD v1 invece delle raccomandazioni della piattaforma di identità Microsoft (v2).
• Usare esempi della community senza verificare che implementino pratiche di sicurezza (PKCE, archiviazione sicura, validazione corretta).

• Non registrare i errori di autenticazione o gli errori di emissione dei token, rendendo difficile la diagnosi.
• Mostrare agli utenti messaggi di errore non elaborati invece di fornire indicazioni utili e operative.

Usa questa guida su registrazione app e OAuth per verificare la tua implementazione, seguire le best practice della piattaforma di identità Microsoft e ridurre i rischi di sicurezza e operativi quando integri OAuth 2.0 con Entra ID.

Prerequisiti per la registrazione dell'app per OAuth

Prima di iniziare con le schermate di registrazione e di incollare il nome della tua app in un portale, verifica alcuni requisiti essenziali. Innanzitutto, ti servono l'accesso all'interfaccia di amministrazione di Microsoft Entra della tua organizzazione o la console appropriata del provider di identità che stai utilizzando: non ci sono scorciatoie. Senza le autorizzazioni corrette, ti troverai bloccato ancora prima di entrare.

Poi decidi che tipo di applicazione stai creando e quali identificatori saranno necessari per il suo funzionamento. È un'app web, un'applicazione a pagina singola, un'app mobile o magari un servizio automatizzato? Ogni tipo ha requisiti specifici in termini di autenticazione e autorizzazione. Definirlo fin dall'inizio orienta le impostazioni di sicurezza che sceglierai in seguito.

È importante anche definire chi utilizzerà la tua applicazione. Ci saranno solo persone della tua organizzazione (single-tenant)? Oppure deve servire utenti di altre aziende o del pubblico in generale (multi-tenant)? Questo influisce sulle impostazioni di registrazione, sulle directory utente applicabili e sul flusso di consenso che vedranno gli utenti.

Infine, raccogli i dettagli tecnici, come gli URL consentiti per i reindirizzamenti di accesso, le piattaforme che supporterai (iOS, Android, Windows?) e le autorizzazioni (o «scope») che l'app dovrà richiedere. Definire questi dettagli in anticipo fa risparmiare molto tempo durante la configurazione ed evita problemi comuni, come URI non validi o tipi di account non corrispondenti in seguito.

Come registrare la tua app con Microsoft Entra ID

Registrare la tua app in Microsoft Entra ID (in precedenza Azure AD) costituisce la base per tutto ciò che riguarda l'autenticazione e l'accesso alle API. Il processo inizia nell'interfaccia di amministrazione di Entra, dove creerai una nuova registrazione dell'app, assegnando alla tua app un'identità univoca (detta «ID client») all'interno della directory dell'organizzazione.

Inserisci un nome per la tua applicazione, quindi scegli chi può usarla: solo la tua organizzazione, più organizzazioni o qualsiasi account Microsoft. Questo passaggio è fondamentale, soprattutto per le app SaaS e B2B, perché determina la portata dell'app e il modo in cui viene gestito il consenso del tenant.

Dopo aver scelto il pubblico, configura i dettagli della piattaforma dell'app. Per le app web aggiungi un URI di reindirizzamento; per le app mobile o a pagina singola, le impostazioni specifiche della piattaforma garantiscono un accesso fluido. Il portale di Entra ti guida nell'aggiunta delle credenziali, come segreti client o certificati, che l'app utilizzerà per dimostrare la propria identità.

Completare la registrazione allinea l'app agli standard OAuth 2.0 e fa in modo che il flusso di autenticazione resti sicuro e conforme. Che tu scelga single-tenant o punti al multi-tenant, comprendere fin da subito queste impostazioni costituisce una base solida per le future esigenze di scalabilità e integrazione.

Vantaggi principali della registrazione dell'app in Microsoft Entra ID

• Gestione centralizzata delle identità: gestisci autenticazione, autorizzazione e identità utente per la tua app da un unico tenant di Entra ID.
• Flussi OAuth sicuri: sfrutta il supporto integrato per OAuth 2.0 e OpenID Connect per implementare accesso sicuro, emissione dei token e accesso delegato.
• Single sign-on (SSO): offri un SSO senza interruzioni su Microsoft 365, Azure e altri servizi integrati, per migliorare l'esperienza utente e ridurre le richieste di password.
• Controllo granulare delle autorizzazioni: definisci e gestisci autorizzazioni API granulari, esperienze di consenso e accesso con privilegi minimi, sia per le autorizzazioni delegate sia per quelle applicative.
• Accesso condizionale e criteri di sicurezza: applica MFA, conformità dei dispositivi, posizione e criteri basati sul rischio per proteggere l'accesso alle applicazioni e i dati sensibili.
• Gestione sicura di segreti e credenziali delle app: archivia e ruota in modo sicuro client secret, certificati e configurazione multi-tenant, seguendo pratiche di gestione del ciclo di vita per preservare l'integrità degli utilizzi delle applicazioni.
• Integrazione con i servizi della piattaforma Microsoft: accedi a Microsoft Graph, alle API di Azure, a Teams e ad altre funzionalità della piattaforma usando token standardizzati e modelli di consenso.
• Supporto per app ibride e multipiattaforma: autentica gli utenti su web, dispositivi mobili, desktop e scenari da servizio a servizio con protocolli di identità coerenti, assicurandoti che ogni applicazione usi gli identificatori corretti.
• Monitoraggio e audit: usa log, report di accesso e informazioni di sicurezza per rilevare anomalie, indagare sugli incidenti e mantenere la conformità.
• Scalabilità e prontezza per l'impresa: sfrutta l'infrastruttura globale di Entra ID, le opzioni multi-tenant e le funzionalità enterprise per supportare basi utenti in crescita ed esigenze organizzative complesse.
• Strumenti per sviluppatori e documentazione: sfrutta gli SDK, il codice di esempio e la guida alla registrazione delle app & a OAuth per accelerare l'implementazione e risolvere i problemi più comuni.

Configurazione degli URI di reindirizzamento e delle impostazioni di piattaforma per le app di Entra ID

Impostare gli URI di reindirizzamento corretti durante la registrazione dell'app sembra semplice, ma questo passaggio è determinante per la sicurezza. Gli URI di reindirizzamento indicano a Entra ID dove inviare gli utenti (insieme ai relativi token) dopo un tentativo di accesso riuscito. Durante la configurazione, Entra applica regole rigorose: niente domini con caratteri jolly, niente schemi URI pericolosi e niente elementi lasciati in sospeso che un malintenzionato potrebbe sfruttare.

Se stai creando un'applicazione a pagina singola (SPA), di solito userai un URL HTTPS che punta al dominio della tua app, per garantire una comunicazione sicura durante l'ottenimento dei dati. Le app native richiedono schemi URI legati al nome del bundle o del pacchetto dell'app, che impedisce ad altre app di dirottare i token sullo stesso dispositivo. Le app web utilizzano in genere i propri endpoint di callback di accesso, e ciascuno deve essere elencato esplicitamente.

Le configurazioni errate portano al classico errore «redirect URI mismatch» e, peggio ancora, aprono la porta agli attacchi che intercettano i token. Dedicare tempo a mappare ogni piattaforma su cui girerà la tua app, insieme ai relativi URI di reindirizzamento, aiuta a garantire un'autenticazione fluida e maggiore tranquillità.

Ricordati di aggiornare la registrazione dell'app ogni volta che cambi gli URL dei client, aggiungi piattaforme o estendi gli ambienti (ad esempio test e produzione). Mantenere questi URI protetti e ordinati è il primo passo per rendere il flusso dei token sicuro.

Nozioni essenziali sui flussi OAuth e sulla gestione dei token

OAuth 2.0 si basa su una serie di flussi di autorizzazione che gestiscono casi d'uso diversi: accessi web, accessi da dispositivi mobili, chiamate da server a server o app eseguite senza un utente presente. Il più diffuso e sicuro di questi è il flusso con codice di autorizzazione, progettato per tenere i token sensibili lontani da browser e app mobili, mettendo la sicurezza al primo posto.

Una volta che l'utente è autenticato e ha concesso il consenso, la tua app riceve un codice a breve durata. Deve scambiare questo codice presso l'endpoint dei token per ottenere i token di accesso e di aggiornamento. Questi token concedono un accesso limitato nel tempo ai dati: quando scadono, il token di aggiornamento può richiedere un nuovo token di accesso per mantenere attiva la sessione.

La gestione dei token non riguarda solo le date di scadenza; significa proteggere i token in ogni fase. Questo implica usare comunicazioni sicure (come HTTPS), non esporre mai i segreti nel codice lato client e applicare il principio del privilegio minimo quando si richiedono gli ambiti.

Questa sezione ti prepara a capire come OAuth gestisce le fasi critiche di scambio tra utenti, app e piattaforme, e in che modo una gestione solida dei token supporti flussi di lavoro persistenti e sicuri, sia per gli utenti finali sia per i sistemi automatizzati.

Implementazione del flusso con codice di autorizzazione OAuth

1. Avvia l'autorizzazione: la tua app reindirizza l'utente all'endpoint di autorizzazione di Entra ID, includendo dettagli come l'ID client, gli ambiti richiesti e un parametro state casuale e univoco per la protezione da CSRF.
2. L'utente concede l'autorizzazione: l'utente esamina la schermata di consenso, che mostra chiaramente le autorizzazioni necessarie alla tua app, e approva l'accesso.
3. Ricevere il codice di autorizzazione: dopo il consenso, Entra ID reindirizza all'URI di reindirizzamento specificato, passando un codice di autorizzazione temporaneo e il valore state impostato inizialmente.
4. Scambiare il codice con i token: il backend invia in modo sicuro il codice, insieme alle credenziali del client (e al code verifier PKCE, se utilizzato), all'endpoint dei token di Entra. Se la verifica ha esito positivo, ottieni i token di accesso (e spesso di aggiornamento).
5. Usare i token per accedere alle API: l'app allega ora il token di accesso a ogni richiesta API, dimostrando l'autorizzazione per conto dell'utente. I token di accesso sono validi solo per un breve periodo, così da ridurre l'esposizione, mentre i token di aggiornamento permettono di ottenere nuovi token di accesso per le sessioni in corso.

Seguire questi passaggi nell'ordine giusto chiude le falle di sicurezza e aiuta a prevenire attacchi come l'intercettazione del codice o l'uso improprio dei token, soprattutto quando lavori con client pubblici o gestisci dati sensibili.

Best practice per la gestione della scadenza dei token di accesso e di aggiornamento

1. Archiviare i token in modo sicuro: usa le soluzioni di archiviazione sicura fornite dal sistema operativo, come Keychain su iOS, Keystore su Android, o gli archivi di segreti crittografati lato server. Non inserire mai i token nei binari dell'app né esporli nei log.
2. Rispettare la durata dei token: monitora il valore di scadenza (claim exp) di ogni token e aggiornalo in anticipo, prima della scadenza, per evitare richieste API non riuscite e una cattiva esperienza utente.
3. Supportare la rotazione dei token: utilizza sempre il token di aggiornamento più recente a ogni richiesta e scarta rapidamente i token riutilizzati o obsoleti. Questo limita l'impatto se un token viene compromesso.
4. Limitare le autorizzazioni per token: richiedi solo gli ambiti (scope) necessari e preferisci token di accesso a breve durata. Questo riduce drasticamente il danno se un token viene divulgato o rubato.

Proteggere le implementazioni OAuth in contesti diversi

Implementare correttamente l'integrazione OAuth significa molto più che spuntare una lista di passaggi: si tratta di costruire più livelli di sicurezza adatti all'architettura della tua app e ai suoi schemi di utilizzo. Che l'app giri nel browser, su uno smartphone o interamente nel cloud, servono strategie di autenticazione calibrate su ciascun contesto.

Tecnologie come PKCE (Proof Key for Code Exchange) blindano il flusso del codice per i client pubblici, impedendo agli attaccanti di intercettare i codici e di scambiarli con token. Per le app che girano in ambienti sicuri, invece, segreti client e certificati diventano gli strumenti migliori per dimostrare l'identità e gestire la fiducia.

Una gestione accurata dei token e un occhio attento ai livelli di privilegio aiutano a evitare fughe accidentali di dati e a limitare il possibile raggio d'azione se qualcosa va storto. Scegliendo gli strumenti di sicurezza giusti (PKCE, segreti, certificati e un corretto ambito delle autorizzazioni), riduci drasticamente la superficie d'attacco e aumenti le probabilità di un funzionamento fluido e conforme.

Di seguito trovi strategie collaudate, efficaci contro le minacce più comuni e utili a personalizzare la configurazione OAuth per una protezione solida in ogni tipo di app e ambiente.

Come PKCE protegge l'autorizzazione OAuth nei client pubblici

PKCE (Proof Key for Code Exchange) è fondamentale quando si usa OAuth nelle app mobili e in quelle basate su browser, cioè nei client pubblici, dove non è possibile archiviare un segreto. Quando avvii il flusso del codice di autorizzazione, l'app genera un "code verifier" casuale e un "code challenge" sottoposto a hash. Questi valori accompagnano l'utente fino alla richiesta finale del token. Anche se un attaccante riesce a sottrarre un codice di autorizzazione, non può scambiarlo con un token senza questo verifier segreto, il che rende quasi impossibili gli attacchi di intercettazione del codice su Microsoft Entra ID e piattaforme simili.

Gestire segreti client, certificati e credenziali federate

• Segreti client: usati dalle app riservate, come i servizi backend attendibili, per dimostrare la propria identità all'endpoint dei token. Archiviali in vault sicuri, ruotali regolarmente e non includerli mai nel codice dell'app lato client.
• Certificati: per un livello di garanzia più alto, usa certificati X.509 al posto dei semplici segreti per rafforzare la sicurezza degli identificatori della tua applicazione. I certificati consentono una convalida più sicura tramite coppie di chiavi pubblica/privata e sono ideali per settori regolamentati o per app soggette a controlli di conformità rigorosi.
• Credenziali federate: per le configurazioni "porta la tua identità" (bring your own identity), usa credenziali federate come l'identità federata di Microsoft Entra o provider esterni. Ciò consente l'autenticazione senza gestire direttamente i segreti, riducendo il carico di gestione.
• Gestione nella pipeline: nei flussi CI/CD, inserisci e ruota segreti e certificati secondo necessità, senza mai codificarli nel controllo del codice sorgente. Gli avvisi automatici di scadenza aggiungono un ulteriore livello di resilienza.

Proteggere i token e ridurre l'esposizione dei privilegi

• Conserva i token solo in posizioni sicure (vault del sistema operativo, ambienti server cifrati), mai in archivi accessibili all'utente.
• Trasmetti sempre i token tramite HTTPS o canali sicuri: il protocollo HTTP in chiaro espone i token all'intercettazione.
• Richiedi per ogni token il minimo di autorizzazioni («scope»): non chiedere mai più di quanto serve alla tua app.
• Verifica regolarmente l'utilizzo dei token e l'assegnazione dei privilegi per evitare un'espansione dei permessi non rilevata.

Buone pratiche per OAuth nelle applicazioni mobili e native

Le app mobili e native presentano oggi difficoltà specifiche: i dispositivi si smarriscono, le app condividono lo spazio di archiviazione e gli utenti si aspettano un accesso rapido e quasi invisibile. Per questo seguire le buone pratiche di OAuth su iOS, Android e desktop, usando gli SDK integrati e meccanismi di archiviazione collaudati, fa davvero la differenza.

L'SDK giusto (come MSAL per Microsoft Entra ID) si occupa di gran parte del lavoro pesante: gestisce i token, la logica di aggiornamento e l'integrazione con l'archiviazione sicura a livello di sistema operativo. Per i token sensibili, questi SDK scelgono di default il repository più sicuro, tenendo conto delle peculiarità specifiche di dispositivo o sistema operativo.

Non trascurare l'esperienza utente: universal link, deep link e flussi tramite browser di sistema aiutano gli utenti a completare l'accesso senza confusione e senza rischi di phishing. Se configurata correttamente, la tua app indirizza l'utente verso una web view di sistema sicura e attendibile, per poi riportarlo in modo sicuro all'interno dell'app al termine dell'accesso: niente pop-up, niente fuga di token.

Queste pratiche non servono solo a proteggere i token, ma anche a costruire la fiducia degli utenti finali, favorendo l'adozione e riducendo in futuro le richieste di assistenza.

Universal link e autenticazione nativa di prima parte

Gli universal link (su iOS) e gli schemi delle app (su Android) rendono l'autenticazione degli utenti molto più sicura. Usando link verificati dal sistema operativo e legati all'identità della tua app, impedisci alle app non autorizzate di intercettare i reindirizzamenti di accesso e di sottrarre token che non gli appartengono. L'autenticazione nativa sfrutta i browser di sistema attendibili, così ad accedere è davvero l'utente reale: phishing, furto di token e accessi accidentali tra app non correlate restano fuori dai giochi. Insieme, questi strumenti offrono un'esperienza fluida e sicura, quasi inattaccabile rispetto alle comuni minacce OAuth su dispositivi mobili.

Risoluzione dei problemi con gli errori OAuth e scenari avanzati

Le integrazioni OAuth raramente funzionano perfettamente al primo tentativo: errori e casi limite insoliti fanno parte del gioco. Spesso i problemi derivano da mancate corrispondenze negli URI di reindirizzamento, codici scaduti o client secret errati, che possono bloccare i flussi di autenticazione e compromettere l'utilizzo delle applicazioni. Questa sezione ti aiuterà a interpretare le risposte di errore, a tracciare gli scambi non riusciti e a risolvere i problemi prima che arrivino al tuo help desk.

Oltre alle basi, alcuni scenari, come la comunicazione tra app server-to-server, l'accesso dei dispositivi IoT o la necessità di garanzie più forti a livello di protocollo, richiedono estensioni OAuth specializzate o flussi non interattivi. Account di servizio, mutual TLS e flussi con codice dispositivo sono progettati appositamente per questi requisiti.

Con indicazioni sia sui guasti più comuni sia sui casi d'uso avanzati, sarai in grado di risolvere i problemi, progettare e mantenere soluzioni OAuth solide, anche quando l'ecosistema delle tue app diventa più complesso.

Che tu stia cercando un errore ostinato nell'endpoint dei token o che tu voglia preparare la tua app al caos del mondo reale (dove dispositivi con input limitato e servizi headless sono ovunque), queste indicazioni ti aiuteranno a mantenere le tue integrazioni fluide e sicure.

Interpretare le risposte di errore OAuth e i fallimenti nello scambio del codice

• URI di reindirizzamento non valido: si verifica quando il reindirizzamento non corrisponde all'elenco registrato; ricontrolla i valori inseriti, maiuscole e minuscole incluse.
• Codice di autorizzazione scaduto: gli utenti impiegano troppo tempo oppure i codici vengono riutilizzati; usali sempre una sola volta e subito dopo averli ricevuti.
• Credenziali client non corrispondenti: è stato fornito il secret o il certificato sbagliato; verifica le credenziali e ruotale quando necessario.
• Scope o risorsa non validi: l'API o gli scope richiesti non sono consentiti oppure contengono errori di digitazione; verifica la configurazione e le autorizzazioni dell'app.

Account di servizio, dispositivi a input limitato ed estensioni OAuth

• Account di servizio (flusso con credenziali client): consentono alle app di autenticarsi senza un utente, ideali per l'automazione e per i processi server-to-server.
• Flusso con codice dispositivo: pensato per smart TV e dispositivi IoT, chiede all'utente di completare l'accesso su un altro dispositivo; è adatto dove non è disponibile un browser.
• Estensione mutual TLS: usa certificati sia per il server sia per il client, rafforzando la sicurezza delle integrazioni sensibili e garantendo che l'applicazione utilizzi metodi di autenticazione robusti.
• Registrazione dinamica dei client: automatizza l'onboarding delle app in SaaS di grandi dimensioni o sistemi multi-tenant, semplificando la gestione delle credenziali su larga scala.

Guida alla registrazione delle app e a OAuth in Entra ID

Pro

• Gestione centralizzata delle identità: si integra con Microsoft Entra ID per garantire un'identità coerente per utenti e app in tutti i servizi.
• Solidi controlli di sicurezza: supporta OAuth 2.0, OpenID Connect, l'accesso condizionale e autorizzazioni granulari (ambiti e ruoli).
• Protocolli standard di settore: sfrutta gli standard OAuth/OIDC, ampiamente supportati, semplificando l'interoperabilità con strumenti e librerie di terze parti.
• Configurazione dettagliata delle app: consente di configurare URI di reindirizzamento, certificati e segreti, autorizzazioni API e opzioni di branding per le app.
• Modello di consenso granulare: supporta autorizzazioni delegate e di applicazione con flussi di consenso dell'amministratore, per limitare le app con privilegi eccessivi.
• Funzionalità per le aziende: supporta app multi-tenant, la collaborazione B2B e l'integrazione con i servizi di Microsoft 365 e Azure.
• Monitoraggio e audit: log, accessi e tracce di audit integrati per le registrazioni delle app e i flussi OAuth, utili per la conformità e la risoluzione dei problemi.
• Strumenti per sviluppatori e SDK: ampia disponibilità di SDK della piattaforma di identità Microsoft, documentazione ed esempi di avvio rapido che semplificano l'implementazione.

Contro

• Complessità per chi inizia: la configurazione e i modelli di autorizzazione (URI di reindirizzamento, URL di risposta, flussi implicito vs. codice di autorizzazione, ambiti) possono confondere i nuovi sviluppatori.
• Curva di apprendimento ripida per le funzionalità di sicurezza: l'accesso condizionale, le identità gestite e le impostazioni avanzate dei token richiedono una conoscenza più approfondita della sicurezza per essere configurati in modo sicuro.
• Rischio di proliferazione delle autorizzazioni: un consenso non corretto o autorizzazioni troppo ampie possono generare app con privilegi eccessivi se non vengono verificate regolarmente.
• Particolarità nella gestione dei token: la gestione dei token di aggiornamento, della durata dei token e della revoca presenta comportamenti specifici della piattaforma che possono causare problemi di integrazione.
• Considerazioni sui confini del tenant: il comportamento delle app multi-tenant e le richieste di consenso dell'amministratore aggiungono complessità operativa negli scenari cross-tenant.
• Modifiche all'interfaccia e alla terminologia: Microsoft aggiorna periodicamente l'interfaccia e i nomi di Entra (Azure AD → Entra ID), il che può creare disallineamenti o confusione con la documentazione.
• Dipendenza dall'ecosistema Microsoft: il forte legame con le funzionalità di Entra ID può limitare la portabilità verso provider di identità non Microsoft senza interventi di riprogettazione.
• Rischio di configurazioni errate: impostazioni errate della registrazione delle app (ad esempio URI di reindirizzamento, URL di risposta, impostazioni del flusso implicito) possono creare falle di sicurezza o interrompere i flussi di autenticazione.

Passi successivi e risorse della community chiave per il successo con OAuth

Bene, OAuth è configurato e funziona, ma non abbassare la guardia: assicurati che l'applicazione per ottenere i token sia configurata correttamente. Impostare le basi è solo il primo passo. Se vuoi che la tua app si distingua e che gli utenti restino al sicuro, è il momento di approfondire gli extra. Inizia a esplorare le librerie client avanzate, sperimenta con Microsoft Graph e scopri le nuove funzionalità di identità che possono rendere la tua integrazione più solida e più fluida per tutti.

Inoltre, non devi risolvere tutto da solo. La documentazione di Microsoft Entra ID è vastissima, con guide aggiornate, esempi di codice e tutte le specifiche tecniche che probabilmente vorrai tenere a portata di mano. Fai l'abitudine di controllare gli aggiornamenti, soprattutto perché gli standard OAuth e dell'identità cloud continuano a evolversi.

Soddisfatto della registrazione dell'app? Ottimo. Ora scopri come gli altri professionisti sul campo usano la creatività. Dai un'occhiata ai forum per sviluppatori, alle community ufficiali e perfino ai repository GitHub delle librerie di autenticazione. Se ti blocchi, è probabile che qualcun altro abbia già risolto esattamente il tuo problema, o almeno se ne sia lamentato abbastanza ad alta voce da ricevere una risposta.

Se ami sperimentare e imparare facendo, prova le prove gratuite disponibili, i tenant di test e le funzionalità in anteprima pubblica. Ti permettono di fare errori (in tutta sicurezza) e capire cosa funziona prima di introdurre le modifiche ai tuoi utenti reali. E non dimenticare che OAuth e la sicurezza sono un impegno collettivo: condividi i tuoi successi e le tue domande. Così contribuisci a mantenere l'ecosistema trasparente e in crescita, aiutando tutti a capire il flusso di OAuth.

Checklist della guida alla registrazione delle app e a OAuth - Entra ID

• Definisci il tipo di applicazione e il modello di accesso: scegli tra tenant singolo, multi-tenant o account Microsoft personali e stabilisci se si tratta di SPA, app web, app mobile, daemon o app di servizio.
• Registra l'applicazione in Entra ID: crea una nuova registrazione app con un nome chiaro e i tipi di account supportati corretti.
• Configura gli URI di reindirizzamento: aggiungi gli URI di reindirizzamento/callback corretti per ogni piattaforma (https, schema personalizzato, localhost per lo sviluppo).
• Imposta le impostazioni della piattaforma dell'applicazione: abilita le opzioni per le piattaforme SPA, web, mobile e desktop e configura i flussi implicit/grant in base alle necessità.
• Crea e gestisci i client secret: genera i client secret per i client riservati, annota la scadenza e conservali in modo sicuro (Key Vault).
• Usa i certificati per l'autenticazione: carica i certificati con chiave pubblica per i client riservati di produzione, al posto dei secret a lunga durata.
• Configura le autorizzazioni API: aggiungi gli ambiti e le autorizzazioni di Microsoft Graph o di API personalizzate richiesti dall'app.
• Concedi il consenso amministratore dove necessario: richiedi e registra il consenso amministratore per le autorizzazioni delegate che richiedono un consenso a livello di tenant.
• Definisci ed esponi gli ambiti personalizzati (se si tratta di un'API): aggiungi gli ambiti in «Esponi un'API» e definisci i nomi degli ambiti, le descrizioni e i nomi visualizzati per il consenso amministratore.
• Configura i ruoli dell'app (se necessari): definisci ruoli applicativi e delegati per il controllo degli accessi basato sui ruoli e assegnali a utenti, gruppi o client app.
• Configura CORS per le SPA che chiamano le API: aggiungi le origini consentite nell'API oppure configura i criteri CORS del gateway.
• Scegli il flusso OAuth 2.0: seleziona Authorization Code (con PKCE per i client pubblici), Client Credentials per le applicazioni daemon oppure Device Code, in base al caso.
• Implementa PKCE per i client pubblici: richiedi Proof Key for Code Exchange per le SPA e le app native, per impedire l'intercettazione del codice.
• Convalida correttamente i token: verifica issuer, audience, firma, scadenza e claim richiesti, usando le librerie di identità Microsoft o la logica di validazione JWT.
• Usa le Microsoft Authentication Libraries (MSAL): preferisci MSAL per l'acquisizione, la memorizzazione nella cache, il rinnovo e la gestione sicura dei token su tutte le piattaforme.
• Configura l'accesso condizionale e MFA (se richiesto): applica i criteri alla registrazione dell'app o ai flussi di accesso degli utenti per imporre i controlli di sicurezza.
• Monitora gli accessi e i log di controllo: abilita la registrazione e controlla gli eventi di accesso, i consensi e le operazioni amministrative nei log di Entra ID.
• Applica il principio del privilegio minimo: richiedi solo le autorizzazioni necessarie e preferisci il consenso incrementale per ridurre l'esposizione.
• Ruota regolarmente i secret e i certificati: implementa la rotazione automatica e gli avvisi per le credenziali in scadenza.
• Proteggi il codice e l'archiviazione lato client: evita di memorizzare segreti nelle app client, usa archivi sicuri e le best practice della piattaforma.
• Testa gli accessi e i flussi di token in sviluppo/staging: verifica i flussi di autenticazione, la durata dei token, la logica di rinnovo, la gestione degli errori e l'esperienza di consenso.
• Prepara la documentazione per utenti e amministratori: includi i passaggi per il consenso, le autorizzazioni richieste e le indicazioni per la risoluzione dei problemi.
• Rivedi e aggiorna periodicamente le registrazioni delle app: verifica autorizzazioni, ruoli, secret e registrazioni per individuare app obsolete o inutilizzate.
• Applica protezioni di rete e delle API: valuta API Management, WAF, rate limiting e service endpoint per proteggere le API di backend.

Uso dei token di accesso Azure, OAuth, autenticazione

Che cos'è la registrazione delle app e la guida OAuth e perché è importante?

Una guida alla registrazione delle app e a OAuth spiega come registrare un'applicazione client presso un provider di identità (ad esempio usando Azure) e implementare i flussi di autorizzazione OAuth 2.0, così che l'applicazione possa richiedere in modo sicuro l'accesso alle risorse protette. Questo è fondamentale che si tratti di applicazioni web, single-page app, app desktop o back-end di server web, perché l'applicazione ha bisogno di un app ID o application ID, di un client ID e, per i client riservati, di un client secret per ottenere un token di accesso e, quando appropriato, ricevere un ID token.

Come registro un'app Azure e ottengo l'application ID e l'app ID?

Per registrare un'app Azure, vai al portale di Azure, crea una nuova registrazione app, indica un nome e gli URI di reindirizzamento, e annota il client ID (application ID) mostrato nella panoramica dell'applicazione. Se la tua applicazione è un client riservato (server web o web tradizionale), crea un client secret da usare insieme al client ID e al client secret. Questa applicazione registrata viene usata nell'autorizzazione e per richiedere token di accesso ai servizi Microsoft.

Quale flusso di autorizzazione OAuth 2.0 dovrei usare per le single-page app?

Le single-page app dovrebbero usare il flusso con codice di autorizzazione e PKCE (Proof Key for Code Exchange) anziché il flusso implicito, così da garantire che l'applicazione ottenga i token in modo sicuro. Il flusso con codice e PKCE consente all'applicazione di scambiare il codice con un access token in modo sicuro da un client basato su browser, permettendo alle single page app di usare OAuth senza esporre i client secret nel browser.

Come funziona la richiesta di autorizzazione e quali parametri sono obbligatori?

Una richiesta di autorizzazione viene inviata all'endpoint di autorizzazione del provider di identità e in genere include client_id (ID dell'app), response_type (ad esempio code), redirect_uri, scope e state. Per le single-page app che usano il flusso con codice e PKCE, si includono anche code_challenge e code_challenge_method. L'utente si autentica e concede il consenso (consenso OAuth), e il server di autorizzazione restituisce un codice all'URI di reindirizzamento, che l'applicazione può scambiare per un access token.

Come si esegue lo scambio tra codice e access token nel codice?

Dopo aver ricevuto il codice di autorizzazione, l'applicazione client invia una richiesta all'endpoint dei token includendo code, client_id (e client_secret per i client riservati), redirect_uri e grant_type=authorization_code. Con PKCE si include anche code_verifier. L'endpoint dei token risponde con un access token, un id token (se richiesto) ed eventualmente un refresh token, utile per ottenere un nuovo access token quando quello attuale scade.

Come si ottiene un access token e come lo si usa per chiamare le API?

Per ottenere un access token, completa il flusso di autorizzazione OAuth 2.0 scelto e chiama l'endpoint dei token. Una volta ottenuto l'access token, invialo nell'intestazione Authorization con lo schema Bearer quando chiami i servizi Microsoft o altre API (ad esempio Google Calendar o API personalizzate). Verifica i token lato server web o lato risorsa, così da assicurarti che le richieste dell'applicazione siano autorizzate.

Cosa fare quando l'access token scade e come ottenere un nuovo refresh token?

Quando l'access token scade, usa il refresh token (se fornito) per richiedere un access token all'endpoint dei token con grant_type=refresh_token. Alcuni flussi o provider possono emettere un nuovo refresh token durante l'aggiornamento, altri possono riutilizzare lo stesso. Se non è disponibile alcun refresh token (client pubblici o flussi di breve durata), reindirizza l'utente alla tua app per eseguire una nuova richiesta di autorizzazione.

Servono registrazioni dell'app separate per le applicazioni web e per quelle mobili o desktop?

Spesso sono necessarie registrazioni separate quando i tipi di applicazione differiscono in modo significativo (ad esempio server web tradizionali, single-page app e applicazioni desktop), perché URI di reindirizzamento, client secret e flussi consentiti variano. Usare registrazioni separate permette di configurare flussi di autorizzazione e URI di reindirizzamento specifici per ciascun tipo di applicazione.

Qual è la differenza tra registrazione dell'app client e applicazione in un tenant?

La registrazione dell'app client è la voce di registrazione specifica nel provider di identità (l'app di Azure) che contiene configurazioni come URI di reindirizzamento e segreti. Un'applicazione in un tenant indica che la registrazione risiede in un determinato tenant di Azure AD e può ricevere ruoli e autorizzazioni all'interno di tale tenant. Una singola registrazione dell'app può essere multi-tenant o single-tenant, a seconda delle esigenze.

Come si richiede l'accesso ai servizi Microsoft e quali autorizzazioni servono?

Richiedi l'accesso specificando nella richiesta di autorizzazione gli scope di cui l'applicazione ha bisogno. Per i servizi Microsoft, configura le autorizzazioni API nella registrazione dell'app di Azure, quindi chiedi agli utenti di concedere il consenso (consenso OAuth) oppure fai in modo che un amministratore conceda il consenso a livello di tenant. L'applicazione richiede scope come User.Read o scope di API personalizzate nell'ambito delle richieste di applicazione e usa l'access token per chiamare i servizi.

Come proteggere i client secret ed evitare la fuga di credenziali nelle single page app?

Le single-page app non dovrebbero memorizzare client secret, perché il codice eseguito nel browser può essere ispezionato. Usa il flusso con codice di autorizzazione e PKCE, così l'applicazione può ottenere in modo sicuro un access token senza client secret. Per le app riservate (server web), conserva client ID e client secret lato server, dove non sono esposti agli utenti.

Qual è il ruolo dell'URI di reindirizzamento e perché deve corrispondere alla registrazione dell'app?

Il redirect URI è il punto a cui il provider di identità invia la risposta di autorizzazione (codice o token). Deve corrispondere al redirect URI registrato nella registrazione dell'app, per impedire il dirottamento della risposta di autorizzazione. Usa la corrispondenza esatta oppure i pattern consentiti definiti dal provider: se non corrispondono, lo scambio del token non andrà a buon fine.

Come faccio a far autenticare gli utenti e ricevere un id token oltre all'access token?

Per ricevere un id token, richiedi lo scope openid e includi un response_type che attivi l'emissione dell'id token (flusso con codice di autorizzazione con openid). L'id token contiene le claim di identità dell'utente autenticato. Usa l'id token per far accedere l'utente alla tua applicazione client e l'access token per chiamare le API downstream.

Quali flussi di autorizzazione specifici si applicano alle applicazioni web tradizionali rispetto alle single page app?

Le applicazioni web tradizionali (lato server) di solito usano il flusso con codice di autorizzazione insieme alle credenziali client (client id e client secret) e scambiano il codice sul web server. Le single page app usano la concessione con codice di autorizzazione con PKCE e senza client secret. Anche le app desktop usano PKCE. Scegli il flusso in base al tipo di applicazione e a dove i segreti possono essere conservati in modo sicuro.

Posso usare una sola registrazione dell'app per più applicazioni client o devo crearne una per ogni app?

Puoi usare una sola registrazione dell'app per più applicazioni client se condividono la stessa configurazione e gli stessi redirect URI, ma le best practice consigliano spesso registrazioni separate per applicazioni distinte, per isolare autorizzazioni, redirect URI e gestione del ciclo di vita. Valuta se l'applicazione potrebbe richiedere scope di autorizzazione diversi o comportamenti di consenso dell'amministratore diversi.

Come faccio a convalidare i token nel mio web server o nella mia API?

Il web server o l'API devono convalidare la firma, l'issuer, l'audience (app id o application id) e la scadenza dell'access token o dell'id token. Usa il documento di discovery del provider per ottenere le chiavi di firma e segui le librerie di convalida consigliate per la tua piattaforma. La convalida garantisce che vengano accettate solo le richieste provenienti da applicazioni autenticate e autorizzate.

Qual è la procedura per richiedere un access token per un servizio backend usando le credenziali client?

Per gli scenari server-to-server, registra un'app in Azure, assegnale le autorizzazioni applicative, quindi usa il flusso con credenziali client: esegui una POST sull'endpoint del token con grant_type=client_credentials, client_id, client_secret e scope/resource. L'endpoint del token restituisce un access token che il backend può usare per chiamare i servizi Microsoft o le API protette.

Come gestisco il consenso OAuth e il consenso dell'amministratore per le applicazioni multi-tenant?

Quando la tua app è registrata come multi-tenant, gli utenti di altri tenant possono concedere il consenso alle autorizzazioni delegate durante la richiesta di autorizzazione. Per le autorizzazioni che richiedono il consenso dell'amministratore, un amministratore deve concedere il consenso per il proprio tenant. Includi istruzioni e un URL di consenso per gli amministratori dei tenant, così da concedere il consenso OAuth su larga scala.

Quali passaggi di risoluzione dei problemi devo seguire se la mia richiesta di autorizzazione non va a buon fine?

Verifica che l'app sia registrata nel portale Microsoft, che il redirect URI corrisponda, che client id e client secret siano corretti, che gli scope siano validi e che il tipo di concessione e gli eventuali parametri PKCE siano corretti. Controlla i messaggi di errore restituiti dall'endpoint di autorizzazione o del token e consulta i log sia lato client sia lato server. Stack Overflow e la documentazione del provider possono aiutarti a interpretare i codici di errore specifici.

Come posso integrare API di terze parti, come Google Calendar, con la mia app registrata?

Per integrare Google Calendar o altre API di terze parti, implementa i flussi di autorizzazione OAuth 2.0 richiesti da tali provider. La tua applicazione deve richiedere gli scope corretti per l'API di terze parti e gestire cicli di vita dei token separati. Potrebbe essere necessario registrare applicazioni client separate presso ciascun provider e coordinare l'ottenimento degli access token per ogni servizio.

Quando devo usare il flusso con codice di dispositivo o altri flussi speciali per determinati dispositivi?

Usa il flusso con codice di dispositivo per i dispositivi con input limitato, dove non è disponibile un browser. Il flusso dispositivo consente a un utente di visitare un URL di verifica su un altro dispositivo per autenticarsi. È uno dei flussi di autorizzazione specifici supportati insieme ai flussi con codice di autorizzazione, credenziali client e refresh token, per adattarsi ai diversi tipi di fattore di forma delle applicazioni.