AADSTS900561: Error de punto de conexión que solo acepta POST

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

Descubre qué significa el error AADSTS900561 de punto de conexión que solo acepta POST, por qué aparece durante el inicio de sesión en Microsoft Entra y cómo solucionarlo de forma segura.

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

Respuesta rápida: el error AADSTS900561 de punto de conexión que solo acepta POST indica que un punto de conexión de autenticación de Microsoft Entra recibió una solicitud con un método no compatible. Revisa el flujo de inicio de sesión de la aplicación, el control de redirecciones y la URL exacta que se abre, en lugar de cambiar repetidamente la configuración de identidad de todo el inquilino.

¿Te has encontrado con el error AADSTS900561 mientras trabajabas con Microsoft Entra ID o Azure Active Directory? Es el que dice «Endpoint only accepts POST requests» («El punto de conexión solo acepta solicitudes POST»). En términos sencillos, significa que tu aplicación intentó comunicarse con el servicio de autenticación de Microsoft usando una solicitud GET, pero el servidor espera una POST. Es como llamar a la puerta trasera cuando deberías haber usado la principal.

Este error aparece con frecuencia cuando desarrollas o integras aplicaciones para Microsoft 365, Azure o Power Platform. Normalmente surge durante los flujos de inicio de sesión o cuando intentas obtener un token de la plataforma de identidad de Microsoft. Entender qué desencadena el error AADSTS900561 es clave, porque te indica exactamente dónde tus llamadas de autenticación no cumplen los requisitos técnicos de Microsoft. A continuación, vamos a desglosar por qué se produce y cómo está relacionado con otro código de error conocido, AADSTS90056.

Descripción y contexto de AADSTS90056 y AADSTS900561

Antes de ponerte a solucionar el problema AADSTS900561, conviene saber exactamente con qué estás tratando. Tanto AADSTS90056 como AADSTS900561 son códigos de error que emite Microsoft Entra ID (antes Azure AD) cuando algo falla en la forma en que tu aplicación se comunica con los puntos de conexión de autenticación. En resumen: AADSTS90056 suele indicar un parámetro de autenticación incorrecto o ausente, mientras que AADSTS900561 se centra en los problemas con el método HTTP, concretamente cuando usas GET donde se requiere POST.

Microsoft Entra ID utiliza reglas de protocolo estrictas para los intercambios de tokens y los flujos de autenticación, a menudo basados en OAuth 2.0. Cuando tu aplicación necesita obtener un token llamando al punto de conexión /token, Microsoft espera que envíes una solicitud POST. No es un capricho: las solicitudes POST permiten enviar datos sensibles de forma segura en el cuerpo de la solicitud, no en la URL, lo que reduce el riesgo de filtraciones y de registros accidentales.

Las solicitudes GET, en cambio, son libros abiertos. Dejan tus datos a la vista en la URL para que cualquiera o cualquier proxy por el camino pueda leerlos. Eso es un problema de seguridad, sobre todo en servicios empresariales que gestionan identidades y datos sensibles. Por eso, la plataforma de identidad de Microsoft exige POST para cualquier acción que implique intercambiar secretos, códigos o información de usuario. Si envías un GET, la plataforma lo detecta y frena en seco con el error AADSTS900561. Entender este contexto técnico te ayuda a saber no solo qué hiciste mal, sino también por qué existe esa regla, y por qué no es negociable en los servicios cloud de Microsoft.

En resumen, si ves cualquiera de estos códigos durante la autenticación, tu aplicación está haciendo una solicitud que no cumple las reglas. Con el contexto de seguridad y de flujo de protocolo fiable que hay detrás de estos códigos de error, tendrás una idea mucho más clara de qué debes corregir y por qué es importante en entornos de aplicaciones profesionales.

Causas habituales y soluciones para los problemas de autenticación AADSTS900561

Si aparece AADSTS900561, casi se puede apostar a que hay un error en la forma en que tu aplicación llama al punto de conexión de tokens de Microsoft. Una de las causas principales: un registro de aplicación mal configurado o un URI de redirección incorrecto en Azure AD. Si el URI de redirección registrado no coincide con el que usa realmente tu aplicación, o le faltan datos obligatorios, puedes provocar sin querer una solicitud GET en lugar de la POST esperada.

Otro error clásico está en la forma en que se programa el propio flujo de autenticación. Algunos desarrolladores usan GET al llamar al punto de conexión /token, sobre todo cuando construyen las solicitudes manualmente o malinterpretan la biblioteca que utilizan. En OAuth 2.0 con Microsoft Entra, la obtención final del token siempre debe enviarse como POST, nunca como GET. Si tu flujo envía un GET en este paso, aparecerá el error AADSTS900561.

Entonces, ¿cómo lo solucionas? Empieza por revisar de nuevo los URI de redirección tanto en el registro de tu aplicación en el portal de Azure como en la configuración local de tu app. Asegúrate de que coincidan exactamente, hasta el protocolo (http o https) y la ruta. Si usas las bibliotecas MSAL o ADAL, comprueba que no estés usando una versión antigua ni escribiendo código que sobrescriba el comportamiento POST por defecto. Si usas tu propio código de autenticación, inspecciona tus llamadas HTTP para confirmar que el endpoint de token siempre recibe una solicitud POST.

¿Necesitas ayuda con el código? Aquí tienes un consejo rápido: en JavaScript, usando fetch o axios, asegúrate de que tu llamada a /token sea similar a method: 'POST'. Si ves "endpoint only accepts post" en tus logs o en el navegador, es la señal para revisar cada paso que da tu código entre la autorización y el intercambio del token, sobre todo si tu app alterna entre lógica de front-end y de back-end. Para profundizar en los riesgos basados en identidad y en soluciones de gobernanza reales, echa un vistazo a este episodio sobre la identidad como plano de control en la seguridad de Azure.

Depuración y buenas prácticas para evitar errores AADSTS900561

Hablemos de cómo localizar este error y asegurarte de que no vuelva a aparecer. Si ejecutas una aplicación de página única (SPA) con React, Vue o Angular, abre las herramientas de desarrollo del navegador. Ve a la pestaña Red, prueba tu flujo de inicio de sesión y busca con atención una solicitud GET al endpoint /token. En cuanto la veas, habrás encontrado al culpable.

A veces este fallo se produce porque la biblioteca de autenticación no está bien configurada. En MSAL.js, por ejemplo, usar loginRedirect cuando en realidad querías acquireTokenSilent, o una configuración incorrecta de la biblioteca, puede hacer que se envíe un GET en lugar de un POST. Actualizar MSAL.js a la última versión y revisar la configuración de inicialización puede ahorrarte muchos dolores de cabeza. Los frameworks son exigentes, pero la documentación de Microsoft es muy clara en cuanto a la necesidad de usar POST en las solicitudes de token.

Tampoco descuides los registros de Azure. Consulta los registros de inicio de sesión de Azure AD para ver trazas detalladas de las solicitudes. Verás qué endpoint se llamó, qué método se usó y si hay indicadores de discrepancias de protocolo. Si necesitas diagnósticos en profundidad, herramientas como Fiddler pueden desglosar el tráfico HTTP línea por línea, y Application Insights puede asociar la pila de llamadas con el punto exacto del problema.

Prevenir es mejor que lamentarse después. Prueba siempre tus flujos de autenticación en desarrollo y en preproducción antes de llevarlos a producción. Asegúrate de que todo el código que intercambia un código de autorización por un token se ejecute en el servidor, con POST, tal como indica la guía de OAuth 2.0. Intercambiar códigos en el navegador es una forma clásica de provocar AADSTS900561 y abrir agujeros de seguridad.

Si trabajas en entornos grandes de Microsoft 365 o Azure, revisa tu enfoque de gobernanza. Entra ID sustenta ahora buena parte del acceso crítico, así que mantener tus directivas bien ajustadas y tu código alineado con las buenas prácticas de Microsoft facilita mucho las cosas. Para saber cómo diseñar una gobernanza que no deje pasar nada por alto, vale la pena echar un vistazo a este episodio sobre la estrategia de gobernanza empresarial en Azure.

Y si tu aplicación forma parte de Power Platform, o simplemente usa conectores, gestiona tus identidades y conectores con cuidado para evitar la deriva arquitectónica y errores de permisos inesperados. Encontrarás orientación práctica en este recurso: buenas prácticas de seguridad y gobernanza de Power Platform.

¿En resumen? Conoce tus flujos de autenticación, valida cada solicitud y mantén tus herramientas actualizadas. Si un error se cuela, sabrás exactamente dónde buscar y cómo erradicarlo para siempre.

Lista de verificación práctica

• Confirma el resultado exacto para el usuario y el alcance afectado.
• Usa la opción de configuración o de comunicación más restringida y segura.
• Prueba la experiencia antes de un despliegue amplio.
• Documenta la responsabilidad, las acciones de seguimiento y los puntos de revisión.

Preguntas frecuentes

¿Cuál es el mejor primer paso?

Identifica el escenario del usuario y el resultado específico que necesitas. Así evitas cambios innecesarios y obtienes una implementación más clara y fiable.

🎧 También te puede interesar escuchar

• Identity Governance in Entra ofrece el contexto de gobernanza en torno a la administración de identidades.
• Microsoft Entra Private Access – Simply Explained explica la arquitectura moderna de identidad y acceso.
• Privileged Identity Management (PIM) – Simply Explained añade contexto sobre el acceso privilegiado para los administradores de Entra.

Última revisión: julio de 2026.