Errore AADSTS900561 su Outlook.com: guida completa e fix “The endpoint only accepts POST requests”

Se i tuoi clienti vedono l’errore AADSTS900561 “The endpoint only accepts POST requests” durante l’accesso a Outlook.com, qui trovi una guida pratica: cause probabili, diagnostica di rete, verifiche su OAuth 2.0 e azioni correttive per ISP e amministratori IT.

Indice

Panoramica del problema

Alcuni utenti, tentando di aprire la webmail di Outlook.com, ottengono il seguente messaggio d’errore:

AADSTS900561: The endpoint only accepts POST requests. Received a GET request.

Secondo le segnalazioni, sono già stati provati senza successo i seguenti interventi lato utente:

Abilitazione di “applicazioni di terze parti” in Azure AD.
Cancellazione di cache e cookie su più browser (Chrome, Edge, Firefox, Opera).
Inserimento manuale dei domini Microsoft nelle impostazioni di “Opzioni Internet” di Windows (inetcpl.cpl).

La caratteristica comune è che la richiesta destinata al token endpoint di Azure AD viene ricevuta come GET, mentre il protocollo OAuth 2.0 richiede tassativamente POST. Questo accade in genere quando un componente intermedio (proxy, firewall, bilanciatore, script di riscrittura URL) modifica il metodo HTTP o produce un redirect che lo trasforma.

Cosa dice Microsoft

Nel thread di riferimento, un moderatore Microsoft (Ankita Vaidya) ha chiarito che l’errore rientra nella sfera di Azure AD e ha invitato l’ISP ad aprire la stessa richiesta su Microsoft Q&A per ricevere supporto specializzato. In pratica: Outlook.com è il “sintomo”, ma la causa è nella catena di autenticazione Azure AD.

Come funziona il tratto di flusso coinvolto

Nel flusso OAuth 2.0 e OpenID Connect, la fase di scambio del codice di autorizzazione con il token avviene verso il token endpoint ed è sempre una richiesta POST con Content-Type: application/x-www-form-urlencoded. L’endpoint tipico ha forma simile a:

https://login.microsoftonline.com/&lt;tenant&gt;/oauth2/v2.0/token

Se questa richiesta diventa un GET, Azure AD la rifiuta e restituisce AADSTS900561. Le trasformazioni POST → GET possono verificarsi quando:

Un proxy applica un redirect con codice 303 See Other (che, per specifica HTTP, cambia il metodo in GET al passo successivo).
Un redirect 301/302 è implementato dal client o dal componente intermedio in modo “legacy”, convertendo in GET.
Una regola di riscrittura cambia esplicitamente il metodo.
Un SSL inspection proxy reinoltra in GET per motivi di compatibilità o per mancanza di configurazione “pass-through”.

Cause tipiche e piani d’azione

Possibile causa	Spiegazione	Azione suggerita
Richiesta GET verso l’endpoint `/token`	Il flusso OAuth 2.0 impone che la chiamata al token endpoint sia una `POST`. Se un proxy, firewall o script di redirezione converte in `GET`, Azure AD rifiuta la richiesta.	Individuare dispositivi o filtri che riscrivono il metodo HTTP; verificare che il client segua un redirect che preservi il metodo.
URL di accesso legacy o hard‑coded	Collegamenti obsoleti possono puntare a risorse che non accettano più `GET` o non sono allineate al percorso moderno.	Verificare che gli utenti aprano `https://outlook.live.com/` o `https://login.microsoftonline.com/` e non URL interni o datati appoggiati a vecchie infrastrutture.
Proxy di autenticazione o filtro HTTPS	Alcuni proxy aziendali intercettano la richiesta e la replicano come `GET` o alterano header critici.	Eseguire un test bypassando il proxy; se il problema sparisce, impostare il proxy in “pass‑through” per i domini Azure/Microsoft e disattivare la riscrittura del metodo.
Configurazione errata in Azure AD (Conditional Access o flussi personalizzati)	Criteri che introducono un salto verso un percorso non standard possono generare redirect incompatibili con lo scambio token.	Rivedere i criteri di Conditional Access, eseguire test con criteri temporaneamente disattivati per isolare l’effetto.

Diagnostica guidata

Prima di aprire un ticket verso Azure AD, segui una procedura di isolamento rigorosa. Questo riduce drasticamente i tempi di soluzione e aiuta a dimostrare dove avviene la conversione POST → GET.

Replica isolata su rete mobile

Collega un dispositivo alla rete mobile o a un hotspot 4G/5G, evitando qualsiasi proxy o appliance di sicurezza.
Ripeti l’accesso a Outlook.com. Se l’errore sparisce, la causa è quasi certamente nella rete dell’ISP o in un proxy locale.

Ispezione con DevTools o Fiddler

Apri gli Strumenti di Sviluppo del browser, scheda Network, e ricarica la pagina di login.
Filtra per richieste contenenti /oauth2/v2.0/token.
Controlla Metodo, Status e la catena di redirect. Cerca codici 301/302/303/307/308.
Se vedi un 303, è normale che il client faccia poi un GET; individua chi ha emesso quel 303 e perché.
Se usi Fiddler, abilita la colonna Method e Host e ordina per Timeline per identificare il punto esatto in cui il metodo cambia.

Verifica del percorso e del metodo

Il token endpoint corretto termina con /oauth2/v2.0/token ed è una POST con corpo x-www-form-urlencoded. Assicurati che:

Il client non stia chiamando /authorize (che è un GET) quando invece deve scambiare token.
Non ci siano rewrite lato proxy che reindirizzano /token verso /authorize o verso portali di captive‑portal.

Raccolta dei dati diagnostici

Quando l’errore viene mostrato dalla pagina Microsoft, annota:

Correlation ID e Trace ID (spesso presenti nella pagina d’errore o negli header risposta come x-ms-request-id, x-ms-ests-server).
Timestamp preciso con fuso orario.
Tenant coinvolto e dominio.
Rete e proxy utilizzati, inclusi IP pubblici e blocchi di rete.
Un HAR o la sessione SAZ di Fiddler con tutta la conversazione.

Esempi pratici per riprodurre e verificare

Verifica con cURL

Comando di esempio per simulare la chiamata a /token. Sostituisci i valori segnaposto con dati non sensibili per un test di connettività:

curl -v \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "clientid=&lt;CLIENTID&gt;&amp;granttype=clientcredentials&amp;scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&amp;clientsecret=&lt;CLIENTSECRET&gt;" \
  "https://login.microsoftonline.com/&lt;TENANTIDOR_NAME&gt;/oauth2/v2.0/token"

Nota importante: se usi -L per seguire i redirect, alcune versioni di cURL convertono la richiesta successiva in GET dopo un 301/302/303. Evita -L durante i test, oppure usa gli switch che preservano il metodo quando appropriato. Per 307/308 il metodo dovrebbe rimanere POST.

Verifica con PowerShell

$body = @{
  clientid     = "&lt;CLIENTID&gt;"
  scope         = "https://graph.microsoft.com/.default"
  granttype    = "clientcredentials"
  clientsecret = "&lt;CLIENTSECRET&gt;"
}
Invoke-RestMethod `
  -Method Post `
  -Uri "https://login.microsoftonline.com/&lt;TENANTIDOR_NAME&gt;/oauth2/v2.0/token" `
  -Headers @{ "Content-Type" = "application/x-www-form-urlencoded" } `
  -Body $body `
  -Verbose

Se in rete aziendale ottieni AADSTS900561 ma in hotspot mobile ricevi un token, il colpevole è la catena proxy/ISP.

Controllo degli header e dei redirect

Nel pannello Network, ispeziona:

Request Method: deve essere POST.
Request Headers: presenza di Content-Type: application/x-www-form-urlencoded, Origin, Referer, Cookie attesi.
Response: eventuali 301/302/303 con Location che punta a host non Microsoft o a captive portal.

Interventi lato rete e proxy

Se l’ISP o l’azienda utilizza appliance di sicurezza, verifica i seguenti aspetti:

SSL inspection: disabilita l’ispezione per i domini di autenticazione Microsoft e Azure. L’ispezione può alterare handshake, header e metodo.
URL rewrite: rimuovi regole generiche che riscrivono tutte le richieste in GET in presenza di redirect o errori di connettività.
Cache: escludi dal caching /oauth2/ e i percorsi di login. Caching aggressivo su POST è sintomo di configurazione errata.
Proxy espliciti vs trasparenti: i proxy trasparenti sono particolarmente inclini a “semplificare” le richieste; verifica che non intervengano su POST autenticati.
Bypass temporaneo: esegui un bypass per i principali FQDN di autenticazione Microsoft per confermare il rientro del problema.

Interventi lato Azure AD

Quando l’errore persiste anche senza proxy, valuta controlli nella configurazione Azure AD:

Conditional Access: criteri complessi o provider di identità esterni possono introdurre redirect. Testa un account con esclusione temporanea dai criteri per isolare l’effetto.
App registrate: verifica che i client non usino endpoint legacy o grant type non più supportati.
Flussi personalizzati: se usi soluzioni B2C o orchestrazioni avanzate, controlla che eventuali pagine intermedie non restituiscano 303 in punti critici.

Checklist tecnica prima dell’escalation

Riproduci il problema su rete mobile, senza proxy o filtri.
Acquisisci tracce con DevTools o Fiddler e identifica dove il POST diventa GET.
Conferma che l’URL chiamato sia quello corretto e termini con /oauth2/v2.0/token.
Raccogli Correlation ID, Trace ID e Timestamp esatti.
Annota dettagli su rete e proxy coinvolti, browser utilizzati e versioni.
Prepara un HAR o una sessione SAZ pulita, senza dati sensibili.

Quali dati includere nella richiesta su Microsoft Q&A

Dominio tenant e, se disponibile, Tenant ID.
Correlation ID e Trace ID così come mostrati nell’errore.
Reti e proxy coinvolti (descrizione, marca/modello, eventuali regole di ispezione/riscrittura).
Log di Fiddler o file HAR con la sequenza completa della sessione.
Browser e versione, sistema operativo.

Percorso decisionale rapido

Errore solo su rete aziendale/ISP → indaga su proxy/SSL inspection/rewrite.
Errore anche su rete mobile → ispeziona la catena OAuth nel client e i criteri Azure AD.
Metodo è già GET alla prima chiamata → l’app o lo script sbagliano endpoint o grant type.
Metodo diventa GET dopo redirect → identifica chi emette 303/302 e perché.

Consigli pratici extra

Evita strumenti che forzano redirect automatici: nelle prove, non usare opzioni che possano cambiare il metodo richiesta senza evidenziarlo.
Attenzione a estensioni browser: estensioni di sicurezza o privacy possono interferire con POST e cookie. Prova in una finestra InPrivate con estensioni disabilitate.
Controllo captive portal: reti guest o hotspot con captive portal possono redirigere tutte le richieste iniziali verso una pagina di login, spesso con conversione a GET.
Allineamento orario: un orologio di sistema molto fuori sincronia può generare errori di auth secondari; sincronizza via NTP.

Domande frequenti

Questo errore riguarda Outlook.com o Azure AD?
Il messaggio è generato dal token endpoint di Azure AD. Outlook.com è la destinazione finale, ma la rottura avviene nella catena di autenticazione.

Perché la cancellazione della cache non aiuta?
Perché la causa frequente è un componente di rete che modifica il metodo HTTP o inserisce redirect impropri. La cache del browser raramente incide sul metodo della richiesta verso /token.

Un 303 See Other è sempre un problema?
Non necessariamente. Ma se segue a una POST del token endpoint, porta a un GET che il server rifiuta. Va capito chi emette quel 303 e perché.

Posso bypassare temporaneamente il proxy?
Sì, è un test fondamentale: se il problema scompare, concentra la ricerca sul proxy e applica esclusioni “pass‑through” per domini e percorsi di autenticazione.

Conditional Access può causare l’errore?
Criteri complessi o flussi personalizzati possono introdurre percorsi non standard o interazioni con IdP esterni che generano redirect incompatibili. Verifica con esclusioni temporanee.

Appendice su pattern di URL e ambito

Riferimenti utili quando analizzi le tracce:

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token → endpoint token, deve essere POST.
/authorize → endpoint di autorizzazione, normalmente GET.
outlook.live.com → interfaccia web Outlook.com (utenze consumer).
La catena può implicare domini aggiuntivi per telemetria, statici e CDN; non devono cambiare il metodo delle richieste POST critiche.

Modello di richiesta per Microsoft Q&A

Titolo: AADSTS900561 su Outlook.com per utenti ISP – conversione POST→GET sul token endpoint

Descrizione:

- Sintomo: AADSTS900561 "The endpoint only accepts POST requests. Received a GET request."
- Ambito: clienti  durante login a Outlook.com
- Riproduzione: sempre/saltuaria (specificare)
- Browser: 
- Rete: 
- Proxy/Firewall: 

Dati diagnostici:

- Timestamp dell’errore: 
- Correlation ID: 
- Trace ID: 
- Tenant/dominio: 
- HAR/SAZ: 

Passi già tentati:

- Cache/cookie puliti
- Esclusione proxy testata
- Verifica metodo su /oauth2/v2.0/token
- Confronto rete mobile vs rete ISP

Richiesta:

- Analisi lato Azure AD per identificare il motivo della conversione del metodo e l’eventuale correzione consigliata

Conclusioni operative

L’errore AADSTS900561 “The endpoint only accepts POST requests” indica che il token endpoint di Azure AD ha ricevuto una richiesta con metodo sbagliato. Nella maggior parte dei casi la responsabilità non è del browser ma di un componente intermedio che ha trasformato la POST in GET, spesso attraverso redirect. La strategia più efficace è isolare la rete, catturare la sequenza di richieste, individuare dove avviene la conversione e mettere in atto esclusioni o correzioni su proxy/filtri. Se, dopo le verifiche, il problema persiste, aprire un caso su Microsoft Q&A con tutti i dati di correlazione consentirà al team Azure di individuare rapidamente la radice e proporre la correzione più adatta.

Passi raccomandati prima di aprire il ticket Azure AD

Riprodurre il problema in rete mobile (senza proxy) per isolare eventuali filtri di rete.
Analizzare con Fiddler o DevTools la sequenza di richieste e identificare dove avviene il passaggio da POST a GET.
Confrontare l’URL chiamato con la documentazione Azure: deve terminare con /oauth2/v2.0/token ed essere POST.
Raccogliere i correlation ID e i timestamp esatti degli errori.

Dati essenziali da fornire su Microsoft Q&A

Dominio tenant
Correlation ID e Trace ID dell’errore
Rete e proxy coinvolti
Log di Fiddler o file HAR
Browser e versione

In sintesi: segui la checklist, conferma dove il metodo cambia, correggi la catena di rete o i criteri, e fornisci a Microsoft Q&A tutti i dati per un’analisi mirata. Così ridurrai drasticamente i tempi di ripristino per gli utenti che accedono a Outlook.com.