Solución completa al error AADSTS900561 en Azure AD: “The endpoint only accepts POST requests”

Cuando el flujo de inicio de sesión en Microsoft 365 falla con el mensaje “AADSTS900561: The endpoint only accepts POST requests. Received a GET request”, la causa suele ser tan sencilla como un método HTTP incorrecto, pero su solución implica revisar el recorrido completo de autenticación. Esta guía exhaustiva explica por qué ocurre, cómo resolverlo y qué prácticas adoptar para que no vuelva a aparecer.

Índice

¿Qué es el error AADSTS900561?

Se trata de una respuesta de Azure Active Directory (Azure AD, ahora Entra ID) que indica que la aplicación o el navegador intentó acceder al endpoint de obtención de tokens con un método GET, cuando dicho endpoint solo admite POST. El servicio, al detectar la solicitud no válida, devuelve un HTTP 405 y el código de error mencionado. El fallo puede presentarse en:

Outlook en la web o de escritorio.
Xbox Cloud Gaming y otros portales de consumo.
Aplicaciones personalizadas que usan MSAL o ADAL.
Flujos híbridos con Exchange Server u otros IdP.

Causas habituales

Redirecciones mal configuradas: un proxy inverso o firewall que transforma una petición POST en GET para cachearla o inspeccionarla.
Error en el código del cliente: bibliotecas obsoletas que degradan a GET tras un reintento.
Cookies corruptas o almacenamiento local dañado que obligan al navegador a repetir el flujo desde cero con el verbo equivocado.
Extensiones del navegador que interceptan y reescriben peticiones (por ejemplo, bloqueadores de anuncios agresivos).
Entornos híbridos o devoluciones 302/307 que, en algún salto, conmutan el método.

Guía paso a paso para eliminar el error

Paso	Acción recomendada	Por qué ayuda
Verificar método HTTP	Asegúrate de que todas las llamadas al endpoint `https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token` se hagan con POST. Si el flujo envía un `GET`, corrige el código o la configuración.	El endpoint de tokens solo admite `POST`; un `GET` provoca el error.
Probar en modo privado y limpiar caché	Abre una ventana InPrivate/Incógnito o borra cookies y caché del navegador.	Cookies expiradas o almacenamiento local corrupto pueden generar redirecciones erróneas que acaban en un `GET`.
Añadir el dominio a “Sitios de confianza” (Windows)	Panel de control → Internet Options → Privacy → Sites → agrega `https://login.microsoftonline.com` y pulsa Allow.	Evita bloqueos de scripts o de terceros que cambien la petición.
Revisar extensiones, proxys y firewalls	Deshabilita extensiones del navegador; inspecciona reglas de proxy/reverse‑proxy y firewall que reescriban o redirijan peticiones.	Algunos dispositivos o complementos transforman `POST` en `GET` para cacheo o inspección.
Confirmar el entorno híbrido	Si usas Exchange híbrido u otro IdP intermedio, verifica los flujos de redirección (Autodiscover, OWA, etc.) y que todos los callbacks sigan siendo `POST`.	Múltiples saltos pueden convertir una respuesta 302 en `GET` y causar el fallo.
Analizar los “Sign‑in Logs” en Azure AD	Usa el Request Id, Correlation Id y Timestamp mostrados en el error para filtrar la entrada y revisar la traza exacta.	Permite identificar qué aplicación o URL inició el `GET` indebido.
Actualizar navegador / usar otro	Instala la versión más reciente de Edge, Chrome, Safari, Firefox o prueba desde otro dispositivo.	Versiones antiguas o bugs específicos pueden generar el `GET`.
Escalar a soporte con datos completos	Si nada funciona, abre un ticket a Microsoft incluyendo los identificadores del error y capturas de red.	El equipo de Azure AD puede rastrear internamente la llamada y proponer un fix.

Detalles técnicos de cada paso

Verificar el método HTTP de la solicitud `/token`

En aplicaciones web, abre las Herramientas de Desarrollador (F12) y comprueba la pestaña Network. El endpoint de emisión de tokens debe aparecer con Method = POST y Status = 200. Si ves GET o 405 Method Not Allowed, tu aplicación está enviando el verbo equivocado.

// Ejemplo de llamada correcta con fetch
await fetch("https://login.microsoftonline.com/common/oauth2/v2.0/token", {
  method: "POST",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded"
  },
  body: new URLSearchParams({
    client_id: "...",
    scope: "openid profile",
    granttype: "authorizationcode",
    code: authCode,
    redirect_uri: "https://contoso.com/auth/callback"
  })
});

Limpiar caché y usar modo InPrivate

Basta con que una cookie de sesión esté dañada para disparar un flujo alterno que fuerce un GET. Abrir una ventana privada elimina ese ruido. Si funciona, el problema es local: borra los datos del sitio o restablece el perfil.

Agregar el dominio a “Sitios de confianza”

En entornos Windows con políticas restrictivas, un nivel de seguridad alto puede impedir que la página de inicio de sesión incruste un <form> con método POST. Al añadir el dominio, la página carga completa y se envía el método correcto.

Inspectores de tráfico y proxies

Dispositivos como F5, Cloudflare, Blue Coat o incluso un load‑balancer corporativo pueden reescribir métodos para cacheo. Revisa la configuración de:

Reescrituras de URI (URL Rewrite).
Políticas de cacheo que cambian POST por GET.
Reglas de inspección TLS que desempaquetan y vuelven a empaquetar peticiones.

Excluye login.microsoftonline.com y *.microsoftonline.com de estas transformaciones.

Entornos híbridos e IdP intermedios

Exchange Server local, ADFS o cualquier IdP SAML pueden introducir redirecciones adicionales. Si en algún paso se envía:

HTTP/1.1 302 Found
Location: https://login.microsoftonline.com/.../token?...

y el cliente sigue la URL resultante con GET, obtendrás el error. Fuerza siempre responsemode=formpost si tu escenario lo permite.

Revisar Sign‑in Logs en el portal de Azure

Ve a Azure Active Directory → Sign‑in logs.
Copia los identificadores del mensaje de error (Request ID, Correlation ID, Timestamp).
Pega cada valor en el filtro correspondiente y aplica.
Abre la entrada y revisa la sección Basic info → Error code → Additional details. Identificarás la aplicación y la IP origen.

Escenarios específicos

Aplicaciones de una sola página (SPA)

Actualiza a la versión más reciente de MSAL.js.
Verifica que uses redirecturi y responsemode=form_post cuando esperes un POST.
Evita concatenar parámetros a mano; usa las utilidades del SDK.

Aplicaciones MVC o Razor Pages

En ASP.NET Core, el middleware Microsoft.Identity.Web gestiona el “authorization code flow”. Asegúrate de:

services.AddMicrosoftIdentityWebAppAuthentication(Configuration)
        .EnableTokenAcquisitionToCallDownstreamApi()
        .AddDistributedTokenCaches();

Versiones anteriores a 1.22 podían degradar a GET ante un error transitorio.

Servicios backend y demonios

El flujo client credentials nunca debe ser GET; revisa bibliotecas antiguas.
Confirma que el servidor no añade Content-Type: text/plain ni sobrescribe la cabecera Expect: 100-continue.

Sistemas con inspección DLP o TLS breaking

Solicita al equipo de redes una excepción de “no‑interceptar” (bypass) para:

https://login.microsoftonline.com
https://login.windows.net
https://login.microsoft.com

La inspección puede modificar la carga útil o forzar un caché GET involuntario.

Pruebas rápidas para verificar la solución

Inicia sesión desde un dispositivo móvil con datos móviles (sin Wi‑Fi corporativo). Si funciona, el proxy es el problema.
Ejecuta un curl manual:
$ curl -X POST -d "client_id=..." "https://login.microsoftonline.com/common/oauth2/v2.0/token" Debe devolver {"error":"invalid_request", ...} o un token, pero nunca 405.
En el navegador, abre about:blank, pega el siguiente snippet y observa el método en la red:
fetch("https://login.microsoftonline.com/common/oauth2/v2.0/token", { method:"POST",body:"",headers:{"Content-Type":"application/x-www-form-urlencoded"} });

Buenas prácticas para evitar la recurrencia

Mantén actualizado el SDK (MSAL, ADAL). Microsoft publica revisiones frecuentes.
Configura responsetype=code y responsemode=form_post para evitar métodos incorrectos en callbacks.
Implementa retry policies con retardo exponencial que no cambien el verbo HTTP durante reintentos.
Documenta rutas de exclusión en proxies y firewalls al desplegar soluciones SaaS basadas en Azure AD.
Audita periódicamente los Sign‑in Logs para detectar picos de AADSTS900561 antes de que afecten a usuarios finales.

Preguntas frecuentes

¿Puedo forzar que Azure AD acepte GET? No. El estándar OAuth 2.0 requiere POST para el endpoint de token porque la carga útil se envía en el cuerpo. Uso un proxy de identidad con Reescritura de URL, ¿qué regla debo crear? Una regla de “passthrough” que preserve el método original para cualquier URL que contenga /oauth2/ o /token. ¿El problema puede estar en la librería MSAL for Android? Versiones anteriores a 4.0.2 enviaban GET tras un error de red IOException. Actualiza al menos a 4.6 o posterior. ¿Por qué en modo InPrivate funciona y en modo normal no? En InPrivate no se usan las mismas cookies ni el almacenamiento de sesión, por lo que se evita la ruta defectuosa que genera la petición GET.

Conclusión

El error AADSTS900561 suele ser consecuencia de una simple violación del protocolo OAuth, pero su raíz puede ser tan diversa como un navegador desactualizado, un proxy celoso o una librería heredada. Siguiendo la guía paso a paso —desde verificar el método HTTP hasta revisar los Sign‑in Logs— podrás restaurar el inicio de sesión normal y blindar tu entorno contra futuras incidencias.