AADSTS900561: errore "Endpoint accetta solo POST"

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

Scopri cos'è l'errore AADSTS900561 "Endpoint only accepts POST", perché si verifica durante l'accesso con Microsoft Entra e come risolverlo in modo sicuro.

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

Risposta rapida: l'errore AADSTS900561 "Endpoint only accepts POST" indica che un endpoint di autenticazione di Microsoft Entra ha ricevuto una richiesta con un metodo non supportato. Controlla il flusso di accesso dell'applicazione, la gestione del reindirizzamento e l'URL esatto che viene aperto, invece di modificare ripetutamente le impostazioni di identità a livello di tenant.

Ti è mai capitato di imbatterti nell'errore AADSTS900561 lavorando con Microsoft Entra ID o Azure Active Directory? È quello che dice "Endpoint only accepts POST requests". In parole semplici, significa che la tua app ha provato a comunicare con il servizio di autenticazione di Microsoft usando una richiesta GET, mentre il server si aspetta una richiesta POST. È come bussare alla porta di servizio quando avresti dovuto usare quella principale.

Questo errore compare spesso quando si creano o si integrano app per Microsoft 365, Azure o Power Platform. Di solito si presenta durante i flussi di accesso o quando si cerca di ottenere un token dalla piattaforma di identità di Microsoft. Capire cosa scatena l'errore AADSTS900561 è fondamentale, perché indica esattamente dove le tue chiamate di autenticazione non rispettano i requisiti tecnici di Microsoft. Ora vediamo nel dettaglio perché viene generato e come è collegato a un altro codice di errore noto, AADSTS90056.

Descrizione e contesto degli errori AADSTS90056 e AADSTS900561

Prima di risolvere il problema AADSTS900561, è utile capire esattamente con cosa hai a che fare. Sia AADSTS90056 sia AADSTS900561 sono codici di errore generati da Microsoft Entra ID (in precedenza Azure AD) quando qualcosa non va nel modo in cui la tua app comunica con gli endpoint di autenticazione. In sintesi: AADSTS90056 di solito segnala un parametro di autenticazione errato o mancante, mentre AADSTS900561 riguarda specificamente i metodi HTTP, cioè quando si usa GET dove è richiesto POST.

Microsoft Entra ID applica regole di protocollo rigorose per gli scambi di token e i flussi di autenticazione, spesso basati su OAuth 2.0. Quando la tua app deve ottenere un token inviando una richiesta all'endpoint /token, Microsoft si aspetta una richiesta POST. Non si tratta di pignoleria: le richieste POST permettono di inviare dati sensibili in modo sicuro nel corpo della richiesta, non nell'URL, riducendo il rischio di fughe di dati e di registrazioni accidentali.

Le richieste GET, invece, sono libri aperti. Inseriscono i tuoi dati direttamente nell'URL, dove possono vederli chiunque o qualsiasi proxy lungo il percorso. È un problema di sicurezza, soprattutto per i servizi aziendali che gestiscono identità e dati sensibili. Per questo la piattaforma di identità di Microsoft impone il metodo POST per qualsiasi operazione che comporti lo scambio di segreti, codici o informazioni utente. Se invii una GET, la piattaforma la intercetta e blocca la richiesta con l'errore AADSTS900561. Capire questo contesto tecnico aiuta non solo a individuare l'errore commesso, ma anche a comprendere perché la regola esiste e perché è non negoziabile in tutti i servizi cloud di Microsoft.

In sintesi, se visualizzi uno di questi codici durante l'autenticazione, la tua app sta inviando una richiesta che non rispetta le regole. Con il contesto di sicurezza e di affidabilità del flusso di protocollo alle spalle, saprai con maggiore chiarezza cosa correggere e perché è importante nei contesti applicativi professionali.

Cause comuni e soluzioni per i problemi di autenticazione AADSTS900561

Se compare AADSTS900561, c'è quasi certamente un errore nel modo in cui la tua app contatta l'endpoint dei token di Microsoft. Una delle cause più frequenti? Una registrazione dell'applicazione configurata in modo errato o un URI di reindirizzamento non corretto in Azure AD. Se l'URI di reindirizzamento registrato non corrisponde a quello effettivamente usato dall'app, oppure mancano dettagli obbligatori, potresti generare involontariamente una richiesta GET al posto della POST prevista.

Un altro errore classico riguarda il modo in cui il flusso di autenticazione è codificato. Alcuni sviluppatori usano per errore una GET quando chiamano l'endpoint /token, soprattutto quando costruiscono le richieste manualmente o hanno frainteso la libreria che stanno utilizzando. In OAuth 2.0 con Microsoft Entra, l'acquisizione finale del token deve sempre essere inviata come POST, mai come GET. Se il tuo flusso invia una GET in questa fase, comparirà subito l'errore AADSTS900561.

Quindi, come si risolve? Inizia verificando con attenzione i redirect URI, sia nella registrazione dell'app nel portale di Azure sia nella configurazione locale della tua app. Assicurati che coincidano esattamente, fino al protocollo (http o https) e al percorso. Se usi le librerie MSAL o ADAL, verifica di non essere su una versione obsoleta e di non scrivere codice che sovrascrive il comportamento POST predefinito. Se usi codice di autenticazione personalizzato, controlla le chiamate HTTP per confermare che l'endpoint del token riceva sempre una richiesta POST.

Ti serve una mano con il codice? Ecco un suggerimento rapido: in JavaScript, con fetch o axios, assicurati che la chiamata a /token sia simile a method: 'POST'. Se nei log o nel browser compare "endpoint only accepts post", è il momento di controllare ogni passaggio del codice tra l'autorizzazione e lo scambio del token, soprattutto se la tua app alterna logica front-end e back-end. Per approfondire i rischi legati all'identità e le soluzioni di governance in scenari reali, dai un'occhiata a questo episodio sull'identità come piano di controllo nella sicurezza di Azure.

Debug e best practice per prevenire gli errori AADSTS900561

Vediamo come individuare questo errore e fare in modo che non si ripresenti. Se hai una single page app (SPA) con React, Vue o Angular, apri gli strumenti di sviluppo del browser. Vai alla scheda Rete (Network), prova il flusso di accesso e tieni d'occhio una richiesta GET verso l'endpoint /token. Appena la vedi, hai trovato il colpevole.

A volte il problema dipende da una libreria di autenticazione configurata male. In MSAL.js, ad esempio, usare loginRedirect al posto di acquireTokenSilent, oppure una configurazione errata della libreria, può far partire una GET invece di una POST. Aggiornare MSAL.js all'ultima versione e ricontrollare le impostazioni di inizializzazione può risparmiarti un sacco di grattacapi. I framework sono esigenti, ma la documentazione Microsoft è chiara: le richieste di token devono usare POST.

Non trascurare nemmeno i log di Azure. Controlla i log di accesso di Azure AD per le tracce dettagliate delle richieste. Vedrai quale endpoint è stato chiamato, con quale metodo e se ci sono segnalazioni di mancata corrispondenza del protocollo. Per diagnostiche approfondite, strumenti come Fiddler possono analizzare il traffico HTTP riga per riga, mentre Application Insights può collegare la chiamata allo stack e indicarti il punto esatto del problema.

Prevenire è meglio che correre ai ripari. Testa sempre i flussi di autenticazione in ambienti di sviluppo e staging prima di rilasciarli in produzione. Assicurati che ogni codice che scambia un codice di autorizzazione con un token venga eseguito lato server, con POST, come indica la guida OAuth 2.0. Scambiare i codici nel browser è un modo classico per incappare in AADSTS900561 e aprire falle di sicurezza.

Se lavori in ambienti Microsoft 365 o Azure di grandi dimensioni, valuta con attenzione il tuo approccio alla governance. Entra ID sostiene ormai gran parte degli accessi critici, quindi mantenere i criteri rigorosi e il codice allineato alle best practice di Microsoft semplifica molto il lavoro. Per capire come progettare una governance che non lasci passare nulla, vale la pena ascoltare questo episodio sulla strategia di governance enterprise di Azure.

E se la tua app fa parte di Power Platform, o usa semplicemente dei connettori, gestisci con cura le identità e i connettori per evitare derive architetturali e sorprese negli errori di autorizzazione. Trovi indicazioni pratiche in questa risorsa: best practice di sicurezza e governance per Power Platform.

In sintesi: conosci i tuoi flussi di autenticazione, convalida ogni richiesta e mantieni aggiornati gli strumenti. Se un errore dovesse comunque presentarsi, saprai esattamente dove guardare e come eliminarlo una volta per tutte.

Checklist pratica

• Conferma il risultato concreto per l'utente e l'ambito interessato.
• Scegli la configurazione o la modalità di comunicazione più ristretta e sicura.
• Testa l'esperienza prima di un rilascio ampio.
• Documenta responsabilità, azioni di follow-up e punti di verifica.

Domande frequenti

Qual è il primo passo migliore?

Individua lo scenario dell'utente e il risultato specifico che ti serve. Così eviti modifiche inutili e ottieni un'implementazione più chiara e affidabile.

🎧 Ascolta anche

• Identity Governance in Entra fornisce il contesto di governance attorno all'amministrazione delle identità.
• Microsoft Entra Private Access – Simply Explained spiega l'architettura moderna per identità e accesso.
• Privileged Identity Management (PIM) – Simply Explained aggiunge il contesto sull'accesso privilegiato per gli amministratori di Entra.

Ultimo aggiornamento: luglio 2026.