Si tus usuarios reciben el mensaje “AADSTS900561: The endpoint only accepts POST requests. Received a GET request.” al intentar acceder a Outlook.com, esta guía exhaustiva te ayudará a entender la causa, aplicar pasos para resolverla y recopilar la información que Microsoft necesita para diagnosticar el incidente con agilidad.

Contexto del error AADSTS900561

El código de error AADSTS900561 proviene de Azure Active Directory (Azure AD) cuando interpreta que el punto de conexión OAuth 2.0 o OpenID Connect al que se envía la solicitud solo admite el método POST, pero ha recibido un GET. Durante el flujo de inicio de sesión, este comportamiento provoca un bloqueo inmediato porque la carga útil que contiene tokens y parámetros de autenticación nunca llega al servicio.

En la práctica, el incidente suele manifestarse en Outlook.com (dominio outlook.live.com) o en aplicaciones construidas sobre Azure AD v2.0 endpoints. Su raíz se encuentra, generalmente, en uno de los tres escenarios siguientes:

• Un bookmark, acceso directo o enlace incrustado fue creado con todos los parámetros de la última sesión. Al reutilizarlo se genera una solicitud GET con datos de la sesión anterior.
• Un componente intermediario (proxy, firewall, antivirus o extensión de navegador) reescribe el paquete HTTP original, cambiando el método POST por GET.
• Una configuración de federación (por ejemplo, AD FS) o un Identity Provider de terceros aplica reglas de reescritura que derivan involuntariamente en la conversión del método.

Cómo se mapea el flujo de autenticación

Para comprender la aparición del error conviene repasar el ciclo de autenticación simplificado:

1. El usuario introduce su dirección de correo en la página de Outlook.com.
2. El navegador envía una solicitud POST con los parámetros clientid, redirecturi y scope al punto de autorización de Azure AD.
3. Azure AD responde con un formulario de inicio de sesión o redirige a un Identity Provider federado.
4. Tras la autenticación, el navegador emite otra solicitud POST con el authorization_code.
5. Si en cualquiera de estos saltos el método se convierte en GET, Azure AD arroja AADSTS900561.

Indicadores clave para el diagnóstico

Antes de aplicar cambios a ciegas, identifica pistas objetivas que reduzcan la superficie de búsqueda:

• Correlation ID y Timestamp: se muestran en la pantalla de error. Anótalos.
• Tenant ID: confirma si la cuenta es Consumer (Outlook.com) o pertenece a un arrendatario corporativo.
• URL completa: comprueba si contiene parámetros persistentes (prompt, login_hint, mkt…).
• Dispositivos y redes: determina si el fallo ocurre solo en una LAN, VPN o ISP concreto.
• Herramientas de inspección: capturas Fiddler/DevTools revelan el método HTTP real.

Pautas de solución escalonada

Aplica la siguiente secuencia. Cada paso está diseñado para aislar variables; avanza al siguiente solo si el anterior no corrige el problema.

Paso	Descripción	Objetivo
Verificar la URL	Accede directamente a https://outlook.live.com/ o escribe la dirección manualmente. Evita marcadores con parámetros previos.	Descartar enlaces GET persistentes que deberían haberse enviado por POST.
Desactivar extensiones, proxys o inspección TLS	Deshabilita temporalmente firewalls, antivirus con HTTPS inspection o extensiones de navegador como bloqueadores de cookies.	Detectar si un intermediario reescribe la petición.
Navegación privada y red alternativa	Inicia sesión desde una ventana privada o desde un móvil con datos celulares.	Aislar problemas de caché y reglas en la red local.
Revisar fecha y hora del sistema	Asegúrate de que el reloj del sistema esté sincronizado por NTP.	Evitar que tokens expirados provoquen flujos anómalos.
Consultar registros de Azure AD	Portal Azure → Azure AD → Sign‑in logs → busca el Correlation ID.	Extraer detalles de la transacción fallida y confirmar el método HTTP.
Auditar IdP federado	Si usas AD FS u otro IdP, revisa reglas de publicación y encabezados X‑HTTP‑Method‑Override.	Verificar que el IdP no fuerce GET.
Escalar a Microsoft	Publica en Microsoft Q&A (espacio Azure AD) o abre un incidente con Tenant ID, Correlation ID, hora exacta y capturas de red.	Obtener soporte especializado.

Análisis de causas frecuentes

Uso de marcadores antiguos

Cuando el usuario marca la pantalla intermedia de autenticación, guarda una URL extensa con parámetros que solo tenían validez en esa sesión. Al reabrirla, el navegador la solicita vía GET. Dado que Azure AD espera un POST con cuerpo, la validación falla.

Inspección de tráfico cifrado

Sistemas de seguridad capaces de romper el túnel TLS —por ejemplo, Zscaler, Blue Coat, Cisco Umbrella— pueden analizar y volver a sellar el paquete. Algunos de estos dispositivos optimizan peticiones AJAX convirtiendo POST en GET para almacenarlas en caché. En entornos corporativos es habitual que el problema aparezca solo al conectarse por VPN.

Antivirus con filtrado HTTPS

Soluciones de escritorio (Kaspersky, Avast, Bitdefender) incluyen módulos de protección web que injectan certificados raíz y, en ocasiones, cambian el método HTTP. Deshabilita la inspección o añade Outlook.com y login.microsoftonline.com a la “lista de exclusiones”.

IdP con reglas de reescritura

Si tu organización federó su dominio mediante AD FS o un proveedor como Okta/PingFederate, existen transformaciones de solicitud (claims rules) que pueden sobrescribir el encabezado Content-Type y obligar a que la respuesta sea recibida como GET. La herramienta adfsdiag de Microsoft o los registros de auditoría Okta revelan la sustitución.

Validación con herramientas de desarrollo

Para confirmar que la petición es de tipo GET:

1. Abre Developer Tools (F12) en Chrome o Edge.
2. En “Network”, marca “Preserve log”.
3. Reproduce la autenticación fallida.
4. Filtra por “login.microsoftonline.com” y observa la columna “Method”.
   Si encuentras una solicitud con método GET y respuesta 302 Redirect inmediata, tienes la evidencia.

Generación de un Fiddler SAZ depurado

En organizaciones que exigen trazas para soporte, sigue esta receta:

1. Instala Fiddler Classic y habilita “Decrypt HTTPS traffic”.
2. Agrega login.microsoftonline.com, outlook.live.com y aadcdn.msauth.net en “Skip Decryption” para evitar exponer tokens.
3. Captura una sesión desde el inicio del navegador hasta el error.
4. Detén la grabación y guarda el archivo .saz.
5. Adjúntalo al ticket de soporte.

Buenas prácticas de prevención

• Distribuye a los usuarios un enlace limpio hacia Outlook.com en los portales internos.
• Configura reglas de los proxies cloud en modo “túnel” o “passthrough” para dominios de Microsoft 365.
• Habilita políticas de grupo (GPO) para impedir el almacenamiento de URLs con parámetros confidenciales en los favoritos corporativos.
• Implementa sincronización horaria con al menos dos servidores NTP redundantes.
• Audita con recurrencia los registros de inicio de sesión de Azure AD detectando picos del error AADSTS900561.

Cuándo involucrar a Microsoft y qué datos aportar

Si después de seguir todos los pasos la incidencia persiste, la vía más eficaz es abrir un ticket de soporte a través del Centro de Administración de Microsoft 365 o del portal Azure. Proporciona:

• Tenant ID y dominio afectado.
• Lista de usuarios y direcciones IP públicas.
• Correlation ID y Timestamp UTC exacto de al menos dos intentos.
• Fichero SAZ con la traza limpia.
• Descripción de pasos reproducibles y medidas ya probadas.

Con esta información, el ingeniero de nivel 2 o 3 podrá comprobar en los metadatos del servicio si un componente de Azure Front Door o un CDN intermedio está interpretando mal las cabeceras, o si es necesario desplegar un hotfix en el servicio de autenticación.

Preguntas frecuentes (FAQ)

¿Este error solo afecta a Outlook.com?

No. Aunque Outlook.com es el escenario más visible, cualquier aplicación que use los puntos de autorización de Azure AD puede presentarlo si se observan las mismas condiciones.

¿Puedo forzar que Azure AD acepte solicitudes GET?

No. El método HTTP está fijado por la especificación de OAuth 2.0. Permitir GET supondría exponer parámetros sensibles en la cadena de consulta, con impacto directo en la seguridad.

¿Restablecer la contraseña ayuda?

No. El error se genera antes de que intervenga la verificación de credenciales; por tanto, cambiar la clave no afecta al flujo.

¿Eliminar cookies soluciona siempre el problema?

Puede ayudar cuando hay tokens corruptos en el navegador, pero no aborda la causa si existe reescritura de método.

Resumen

El error AADSTS900561 se produce cuando Azure AD recibe una solicitud GET allí donde espera un POST. La mayoría de las veces, la transformación sucede en la capa del navegador, un proxy de inspección HTTPS o un marcador obsoleto. Siguiendo el itinerario propuesto —verificar URL, desactivar filtros, usar otra red, revisar hora del sistema, comprobar registros, auditar IdP y, por último, escalar a Microsoft— podrás:

• Solucionar las causas comunes sin intervención externa.
• Recopilar evidencias técnicas sólidas que aceleren la resolución por parte de Microsoft.
• Implementar controles preventivos para evitar recurrencias.

Aplicar un enfoque metódico no solo resuelve el incidente puntual, sino que fortalece la postura de autenticación de tu organización frente a futuras actualizaciones del ecosistema Microsoft 365.