Risolvere il problema AADSTS700054 "Response Type Not Enabled" nelle app di Azure AD

By Mirko Peters · 2026-04-21

Ti è mai capitato di imbatterti nell'errore AADSTS700054 e di chiederti: «Cosa ho combinato stavolta?» Non sei il solo. Questo errore è noto per comparire proprio quando provi ad autenticare un'app con Azure Active Directory, soprattutto con Microsoft 365, Dynamics 365 o le tue single page app. In sostanza significa che la tua app non è configurata per accettare lo specifico «response type» richie

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

Ti è mai capitato di imbatterti nell'errore AADSTS700054 e di chiederti: «Cosa ho combinato stavolta?» Non sei il solo. Questo errore è noto per comparire proprio quando provi ad autenticare un'app con Azure Active Directory, soprattutto con Microsoft 365, Dynamics 365 o le tue single page app. In sostanza significa che la tua app non è configurata per accettare lo specifico «response type» richiesto, come un ID token o un access token dall'endpoint di autorizzazione.

Questa guida spiega perché succede e ti accompagna nella correzione, sia per le vecchie applicazioni basate sull'implicit grant sia per le configurazioni moderne che usano MSAL.js e PKCE. Troverai anche le best practice per rendere sicure le configurazioni, oltre a qualche indicazione su risorse della community e sulla navigazione del blog per trovare rapidamente le risposte. Alla fine, che tu stia risolvendo problemi su app legacy o moderne, saprai esattamente come risolvere e prevenire questo fastidioso problema di autenticazione.

Capire le cause del problema AADSTS700054

L'errore AADSTS700054 non è un codice criptico qualsiasi. È, in pratica, il modo in cui Azure ti dice: «La tua app mi ha chiesto qualcosa che non è autorizzata ad avere». Di solito riguarda i response type. Quando l'applicazione prova a richiedere un token ad Azure AD ma non è configurata per quel «flusso» (come l'implicit grant), Azure blocca la richiesta e ti mostra questo errore.

Perché si presenta? Nella maggior parte dei casi, compare perché la registrazione dell'app non ha le impostazioni corrette per gli ID token, gli access token o entrambi, sull'endpoint di autorizzazione. Ad esempio, immagina una single page application (SPA) che prova a ottenere token con il flusso implicito senza che sia abilitato in Azure AD. Azure rileva la discrepanza tra ciò che viene richiesto e ciò che è effettivamente consentito e, zac, ottieni AADSTS700054.

Le configurazioni errate sono frequenti quando si passa dagli approcci di autenticazione legacy alle best practice moderne. Le organizzazioni che supportano sia app più vecchie (che potrebbero ancora usare l'implicit grant) sia app più recenti (che dovrebbero usare PKCE e il flusso con codice di autorizzazione) sono particolarmente esposte. Stai aggiornando l'autenticazione cloud o integrando nuovi servizi Microsoft? La probabilità di incappare in questo intoppo aumenta.

Capire questo errore ti permette di collegare ciò che il codice richiede con ciò che l'app Azure è configurata a gestire. Per questo, nel resto della guida, vedrai come allineare le richieste di token dell'applicazione a quanto si aspetta Microsoft Identity Platform, così sarai un passo avanti nella risoluzione dei problemi.

Abilitare la soluzione consigliata per i problemi di response type con implicit grant

Se AADSTS700054 blocca la tua integrazione, il rimedio più rapido di solito è configurare la registrazione dell'app con i response type corretti. Spesso significa abilitare le impostazioni dell'implicit grant, in sostanza dando all'app il permesso di richiedere token direttamente dall'endpoint di autorizzazione.

Ecco come procedere nel portale di Azure: prima di tutto, vai su «Registrazioni app», trova l'applicazione interessata e apri la sezione «Autenticazione». Cerca l'area «Concessione implicita e flussi ibridi». Lì vedrai le caselle «Token di accesso» e «Token ID». Seleziona quelle appropriate per il tuo scenario: di solito le SPA hanno bisogno almeno della casella «Token ID», mentre le app più vecchie potrebbero aver bisogno di entrambe.

Ma non spuntare tutto sperando nel meglio! Abilita solo le opzioni di cui l'app ha effettivamente bisogno, tenendo la sicurezza al primo posto. Se la tua app richiede token tramite l'endpoint di autorizzazione, come fanno la maggior parte delle app basate su browser, queste impostazioni sono obbligatorie. Per le altre, soprattutto quelle che passano a flussi più sicuri (come PKCE), potrebbe non essere necessario toccare l'implicit grant.

Una volta applicate queste modifiche, la maggior parte dei problemi legati ad AADSTS700054 si risolve subito. Se il problema persiste, verifica l'ambito dei permessi dell'app, gli URI di reindirizzamento e che le modifiche si siano propagate completamente nel tuo account. Questo è il punto di partenza per affrontare l'errore e far tornare utenti e sviluppatori al lavoro.

Best practice di sicurezza per evitare configurazioni errate del response type

Modificare le impostazioni del flusso implicito può risolvere un errore, certo, ma non è sempre il piano più sicuro a lungo termine. Abilitare il flusso implicito aumenta il rischio per la sicurezza, perché i token vengono restituiti direttamente nelle risposte del browser e possono quindi essere intercettati più facilmente. Per questo Microsoft, e sinceramente ogni amministratore attento alla sicurezza, consiglia di usare alternative moderne come il Flusso del codice di autorizzazione con PKCE nella maggior parte degli scenari, soprattutto per le SPA nuove o aggiornate.

Quindi, quando conviene abilitare il flusso implicito? In breve: solo se hai app legacy o casi particolari che lo richiedono. Per tutto il resto, configura le tue app in modo che usino il flusso del codice di autorizzazione (con PKCE). In questo modo i token restano fuori dalla barra degli indirizzi del browser e la superficie di attacco si riduce in modo significativo.

Le organizzazioni che combinano Power Platform, Microsoft 365 e Dynamics 365 non possono permettersi di trascurare queste best practice. Tipi di risposta configurati in modo errato non si limitano a interrompere gli accessi: possono aprire varchi per gli attaccanti o creare problemi di conformità in un secondo momento. Questa panoramica su sicurezza e governance di Power Platform spiega perché sono davvero importanti controlli rigorosi e la conoscenza dei flussi scelti, soprattutto quando i citizen developer aggiungono app personalizzate e integrazioni.

In sintesi: abilita solo ciò che serve, preferisci il flusso del codice con PKCE dove possibile e proteggi le registrazioni delle app come parte di una più ampia strategia di governance. Assicurati che tutte le impostazioni siano allineate ai criteri di sicurezza che vuoi far rispettare: il tuo io futuro (e i tuoi auditor) ti ringrazieranno.

Risoluzione dei problemi di AADSTS700054 nelle app moderne con MSAL.js

Verrebbe da pensare che passare alle librerie di autenticazione moderne come MSAL.js v2+ e PKCE ti metta al riparo dagli errori "vecchia scuola" come AADSTS700054, giusto? Non così in fretta. Anche le Single Page Application moderne possono incepparsi se la registrazione dell'app o le configurazioni lato client non sono allineate alle best practice attuali.

Il colpevole principale? Presupposti superati. Gli sviluppatori possono passare a MSAL.js mantenendo però URI di reindirizzamento legacy o richiedendo per errore tipi di risposta (come id_token) che in Azure AD non sono abilitati. Questo succede soprattutto quando il manifesto dell'app è copiato da un altro progetto. Il risultato: quando l'app avvia il flusso di autenticazione, Azure AD restituisce quel temibile errore.

Come fare il debug? Apri gli strumenti di sviluppo del browser, vai nella scheda Rete e osserva la richiesta di autorizzazione. Verifica che il tuo response_type corrisponda ai flussi che l'app Azure è effettivamente configurata ad accettare. Se vedi richieste di token che non sono abilitate correttamente, torna al portale di Azure e adegua di conseguenza la registrazione dell'app.

Ricorda: con MSAL.js v2 e PKCE, di solito non serve abilitare affatto il flusso implicito. Ma se l'app continua a non funzionare, cerca impostazioni "implicit" hard-coded, errori di battitura negli URI di reindirizzamento o tipi di concessione non corretti. Una revisione attenta della configurazione, sia lato Azure sia lato client, risolve la maggior parte dei problemi. Non sarà una attività entusiasmante, ma una risoluzione dei problemi metodica fa risparmiare ore di tentativi alla cieca.

Migrazione delle applicazioni legacy dal flusso implicito a PKCE

Pronto a lasciarti alle spalle il flusso implicito per sempre? Ottima scelta. La migrazione a PKCE (Proof Key for Code Exchange) è ormai lo standard di riferimento, e Microsoft lo raccomanda vivamente. Ma, siamo sinceri, migrare un'app in produzione con utenti attivi non si riduce mai a cambiare un'impostazione. Serve un piano che eviti interruzioni del servizio, riduca al minimo i disagi nell'accesso e tenga informate tutte le persone coinvolte.

Il primo passo è valutare e inventariare tutte le registrazioni delle app che usano il flusso implicito. Poi, testa il nuovo flusso basato su PKCE in un ambiente di staging. Questo significa impostare l'app per usare il flusso del codice di autorizzazione, aggiornare gli URI di reindirizzamento e modificare i file di configurazione del client (come le sostituzioni di MSAL.js o ADAL.js). Esegui cicli completi di accesso e disconnessione e di rinnovo dei token. Verifica che funzioni per tutti i tipi di utente.

Prima di attivare la modifica in produzione, prepara un piano di rollback. Potresti dover mantenere temporaneamente entrambi i flussi abilitati se la migrazione non va liscia. Comunica chiaramente con gli utenti: non amano le sorprese, soprattutto se il lavoro si blocca per una modifica non annunciata al modo in cui effettuano l'accesso.

Infine, fai attenzione a problemi come il mancato rinnovo dei token o le sessioni attive interrotte dopo la migrazione. Se possibile, pianifica gli aggiornamenti in orari a basso traffico. Ti serve altro per rendere operative queste transizioni? Alcune risorse rimandano ad altri siti, ma puoi sempre consultare gli ultimi podcast su Microsoft 365 Copilot e sull'architettura per spunti indiretti sulla gestione del cambiamento in azienda (guarda qui le discussioni recenti).

Scoprire blog affidabili come quello di Nishant Rana per soluzioni sicure

• Weblog di Nishant Rana: un riferimento imprescindibile per risolvere i problemi di integrazione con Azure AD. Nishant tratta scenari approfonditi, soluzioni passo passo e anche casi particolari per Dynamics 365 e Power Platform. Le sue guide chiare rendono molto meno ostici gli errori di autenticazione più complessi.
• Blog KingswaySoft MVP: noto per i consigli pratici sull'integrazione dei dati CRM, questo blog curato da MVP affronta regolarmente i casi limite dell'autenticazione, aspetto essenziale per chi lavora con Azure AD e con l'ecosistema di Microsoft 365.
• Top 100 CRM Blog: le classifiche di questo tipo mettono in luce la più ampia comunità tecnica e permettono di scoprire autori che pubblicano regolarmente su identità, sicurezza e risoluzione dei problemi in ambito Microsoft. Ampliare la lista delle letture aumenta le probabilità di trovare una soluzione adatta al tuo caso specifico.

Usare la ricerca rapida e gli archivi per trovare post recenti sui problemi di Azure AD

• Usa le funzioni di ricerca rapida: la maggior parte dei blog tecnici autorevoli ha una barra di ricerca, usala! Digita «AADSTS700054», «Azure AD error» o «implicit grant» per trovare subito post e guide direttamente pertinenti al tuo problema. È molto più veloce che sfogliare manualmente.
• Consulta gli archivi e gli aggiornamenti recenti: se la ricerca non fa emergere il tuo problema, esplora gli archivi del sito o gli elenchi filtrati dei «post più recenti». Molte guide di troubleshooting collaudate si nascondono nei contenuti più vecchi, e a volte un post recente contiene la soluzione esatta per le nuove modifiche all'autenticazione della piattaforma Microsoft.
• Combina i filtri per gli utenti esperti: vuoi fare un passo in più? Usa i sistemi di tag o categorie insieme alla ricerca. Filtrare tutti i post su «Azure AD» o restringere il campo a «app registration» ridurrà i tempi di troubleshooting e ti farà scoprire problemi e soluzioni che altrimenti sarebbero sfuggiti.