Cómo solucionar el problema AADSTS700054 "Response Type Not Enabled" en las aplicaciones de Azure AD

By Mirko Peters · 2026-04-21

¿Alguna vez te has topado con el error AADSTS700054 y te has preguntado: "¿Qué he hecho mal esta vez?" No eres el único. Este error es conocido por aparecer justo cuando intentas autenticar una aplicación con Azure Active Directory, sobre todo con Microsoft 365, Dynamics 365 o tus propias aplicaciones de página única. En esencia, significa que tu aplicación no está configurada para aceptar el "tip

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

¿Alguna vez te has topado con el error AADSTS700054 y te has preguntado: "¿Qué he hecho mal esta vez?" No eres el único. Este error es conocido por aparecer justo cuando intentas autenticar una aplicación con Azure Active Directory, sobre todo con Microsoft 365, Dynamics 365 o tus propias aplicaciones de página única. En esencia, significa que tu aplicación no está configurada para aceptar el "tipo de respuesta" específico que solicita, como un token de identificador o un token de acceso desde el endpoint de autorización.

Esta guía explica por qué ocurre y te muestra cómo solucionarlo tanto en aplicaciones antiguas basadas en la concesión implícita como en configuraciones modernas que usan MSAL.js y PKCE. También encontrarás buenas prácticas para que tus configuraciones sean seguras, además de referencias a recursos de la comunidad y consejos para navegar por el blog y encontrar respuestas rápido. Al final, ya sea que estés resolviendo problemas en aplicaciones heredadas o modernas, sabrás exactamente cómo resolver y evitar este dolor de cabeza de autenticación tan común.

Entender las causas del problema AADSTS700054

El error AADSTS700054 no es otro código críptico de Microsoft. En el fondo, es la forma en que Azure te dice: "Tu aplicación me ha pedido algo que no tiene permitido". Normalmente, tiene que ver con los tipos de respuesta. Cuando tu aplicación intenta solicitar un token a Azure AD pero no se ha configurado para ese "flujo" (como la concesión implícita), Azure bloquea la solicitud y te muestra este error directamente.

¿Por qué aparece? En la mayoría de los casos, se debe a que el registro de tu aplicación no tiene la configuración correcta para los tokens de identificador, los tokens de acceso o ambos, en el endpoint de autorización. Por ejemplo, imagina una aplicación de página única (SPA) que intenta obtener tokens mediante el flujo implícito sin tenerlo habilitado en Azure AD. Azure detecta esta discrepancia entre lo que se solicita y lo que realmente está permitido, y, ¡zas!, aparece AADSTS700054.

Los errores de configuración son frecuentes cuando se pasa de los enfoques de autenticación heredados a las prácticas modernas. Las organizaciones que dan soporte tanto a aplicaciones antiguas (que todavía pueden usar la concesión implícita) como a aplicaciones nuevas (que deberían usar PKCE y el flujo de código de autorización) son especialmente vulnerables. ¿Estás actualizando la autenticación en la nube o integrando nuevos servicios de Microsoft? Las probabilidades de encontrarte con este obstáculo aumentan.

Entender este error te permite relacionar lo que tu código solicita con lo que tu aplicación de Azure está configurada para gestionar. Por eso, a lo largo del resto de esta guía verás cómo alinear las solicitudes de tokens de tu aplicación con lo que espera Microsoft Identity Platform, para que vayas un paso por delante en la resolución de problemas.

Habilitar la solución recomendada para los problemas de tipo de respuesta de la concesión implícita

Si AADSTS700054 está bloqueando tu integración, la solución más rápida suele ser configurar el registro de tu aplicación con los tipos de respuesta adecuados. Normalmente, eso implica habilitar la configuración de concesión implícita, es decir, dar a tu aplicación permiso para solicitar tokens directamente desde el endpoint de autorización.

Así es como lo gestionas en Azure Portal: primero, ve a "Registros de aplicaciones", busca la aplicación afectada y abre la sección "Autenticación". Busca el área "Concesión implícita y flujos híbridos". Ahí verás casillas para "Tokens de acceso" y "Tokens de identificador". Marca las que correspondan a tu escenario: normalmente, las SPA necesitan como mínimo la casilla "Tokens de identificador", y las aplicaciones más antiguas pueden necesitar ambas.

Pero no lo actives todo y confíes en que funcione. Habilita únicamente las opciones que tu aplicación realmente necesita, teniendo siempre presente la seguridad. Si tu aplicación solicita tokens a través del endpoint de autorización, como hacen la mayoría de las aplicaciones basadas en navegador, estas opciones son necesarias. En otros casos, sobre todo si estás migrando a flujos más seguros como PKCE, es posible que no necesites tocar la concesión implícita en absoluto.

Una vez aplicados estos cambios, la mayoría de los problemas con AADSTS700054 se resuelven de inmediato. Si sigues atascado, revisa el ámbito de permisos de tu aplicación, los URI de redirección y si los cambios se han propagado completamente en tu cuenta. Esa es la base para abordar este error y devolver a los usuarios (y a los desarrolladores) a su trabajo.

Prácticas recomendadas de seguridad para evitar errores de configuración del tipo de respuesta

Ajustar la configuración de la concesión implícita puede resolver un error, claro, pero no siempre es el plan más seguro a largo plazo. Habilitar el flujo implícito aumenta el riesgo de seguridad, ya que los tokens se devuelven directamente en las respuestas del navegador, lo que los hace potencialmente más fáciles de interceptar. Por eso Microsoft, y sinceramente cualquier administrador consciente de la seguridad, recomienda usar alternativas modernas como el flujo de código de autorización con PKCE para la mayoría de escenarios, sobre todo en SPA nuevas o actualizadas.

Entonces, ¿cuándo deberías habilitar la concesión implícita? En resumen, solo si tienes aplicaciones heredadas o casos especiales que lo exijan. Para todo lo demás, configura tus aplicaciones para usar el flujo de código de autorización (con PKCE). Así los tokens no aparecen en la barra de direcciones del navegador y la superficie de ataque se reduce considerablemente.

Las organizaciones que combinan Power Platform, Microsoft 365 y Dynamics 365 no pueden permitirse descuidar estas buenas prácticas. Una configuración incorrecta de los tipos de respuesta no solo rompe los inicios de sesión: puede abrir puertas a atacantes o provocar problemas de cumplimiento normativo más adelante. Este resumen sobre seguridad y gobernanza de Power Platform explica por qué es tan importante contar con controles estrictos y conocer bien los flujos que utilizas, especialmente cuando los desarrolladores ciudadanos añaden aplicaciones personalizadas e integraciones.

En resumen: habilita solo lo necesario, prefiere el flujo de código con PKCE siempre que sea posible y protege tus registros de aplicaciones como parte de una estrategia de gobernanza más amplia. Asegúrate de que toda la configuración esté alineada con las directivas de seguridad que quieres aplicar. Tu yo del futuro (y tus auditores) te lo agradecerán.

Solución de problemas de AADSTS700054 en aplicaciones modernas con MSAL.js

Cabría pensar que pasar a bibliotecas de autenticación modernas como MSAL.js v2+ y PKCE te libraría de errores "de la vieja escuela" como AADSTS700054, ¿verdad? Pues no tan rápido. Incluso las aplicaciones modernas de página única pueden tropezar si su registro de aplicación o su configuración del lado cliente no están alineados con las buenas prácticas actuales.

¿El principal culpable? Suposiciones antiguas. Los desarrolladores pueden empezar con MSAL.js pero mantener URI de redirección heredados o, sin querer, solicitar tipos de respuesta (como id_token) que no están habilitados en Azure AD. Esto ocurre sobre todo cuando el manifiesto de la aplicación se ha copiado y pegado desde otro proyecto. El resultado: Azure AD devuelve ese temido error en cuanto la aplicación inicia el flujo de autenticación.

¿Cómo depurarlo? Abre las herramientas de desarrollo de tu navegador, ve a la pestaña Red y observa la solicitud de autorización. Verifica que tu response_type coincida con los flujos que tu aplicación de Azure realmente acepta. Si ves solicitudes de tokens que no están habilitadas correctamente, vuelve al portal de Azure y ajusta el registro de la aplicación en consecuencia.

No olvides que con MSAL.js v2 y PKCE normalmente no necesitas habilitar el flujo implícito en absoluto. Pero si tu aplicación sigue fallando, busca configuraciones "implicit" codificadas de forma fija, erratas en los URI de redirección o tipos de concesión incorrectos. Una revisión cuidadosa de la configuración, tanto en Azure como en el lado cliente, resuelve la mayoría de los problemas. No es lo más vistoso, pero una solución de problemas bien hecha ahorra horas de conjeturas.

Migración de aplicaciones heredadas de la concesión implícita a PKCE

¿Listo para dejar atrás el flujo implícito para siempre? Buena decisión. Migrar a PKCE (Proof Key for Code Exchange) es hoy el estándar de referencia, y Microsoft lo recomienda encarecidamente. Pero, siendo realistas, migrar una aplicación en producción con usuarios nunca es solo cuestión de cambiar un ajuste. Necesitas un plan que evite tiempos de inactividad, minimice las interrupciones en el inicio de sesión y mantenga informado a todo el mundo.

El primer paso es evaluar e inventariar todos los registros de aplicación que usan la concesión implícita. A continuación, prueba el nuevo flujo basado en PKCE en un entorno de pruebas. Esto implica configurar la aplicación para usar el flujo de código de autorización, actualizar los URI de redirección y ajustar los archivos de configuración del cliente (como los reemplazos de MSAL.js o ADAL.js). Ejecuta ciclos completos de inicio y cierre de sesión y de renovación de tokens. Asegúrate de que funciona para todos los tipos de usuario.

Antes de activarlo en producción, ten un plan de reversión. Es posible que necesites mantener ambos flujos habilitados temporalmente si la migración no sale como esperas. Comunica con claridad a tus usuarios: no les gustan las sorpresas, sobre todo si su trabajo se detiene por un cambio no anunciado en la forma de iniciar sesión.

Por último, vigila problemas como fallos en la renovación de tokens o sesiones activas interrumpidas tras la migración. Si es posible, programa las actualizaciones en momentos de poco tráfico. ¿Necesitas más información sobre cómo operacionalizar estas transiciones? Aunque algunos recursos redirigen, siempre puedes consultar los últimos podcasts sobre Microsoft 365 Copilot y arquitectura para encontrar pistas indirectas sobre la gestión del cambio en entornos empresariales (consulta aquí los debates recientes).

Cómo descubrir blogs de confianza como el de Nishant Rana para encontrar soluciones fiables

• Nishant Rana’s Weblog: Un recurso de referencia para resolver problemas de integración de Azure AD. Nishant cubre escenarios en profundidad, soluciones paso a paso e incluso casos muy específicos de Dynamics 365 y Power Platform. Sus explicaciones claras hacen que los errores de autenticación más complicados resulten mucho menos intimidantes.
• KingswaySoft MVP Blog: Conocido por sus consejos prácticos sobre integración de datos de CRM, este blog dirigido por MVP aborda con regularidad casos límite de autenticación, algo esencial para cualquiera que trabaje con Azure AD y el ecosistema de Microsoft 365.
• Top 100 CRM Blogs: Listas recopiladas como esta dan visibilidad a la comunidad técnica en general y te permiten descubrir autores que publican con frecuencia sobre identidad, seguridad y resolución de problemas en Microsoft. Ampliar tu lista de lectura aumenta tus probabilidades de encontrar una solución adaptada a tu caso concreto.

Cómo usar la búsqueda rápida y los archivos para localizar publicaciones recientes sobre problemas de Azure AD

• Usa las funciones de búsqueda rápida: La mayoría de los blogs técnicos de referencia tienen un cuadro de búsqueda, ¡así que úsalo! Escribe «AADSTS700054», «error de Azure AD» o «implicit grant» para encontrar al instante publicaciones y guías directamente relacionadas con tu problema. Es mucho más rápido que navegar manualmente.
• Consulta los archivos y las últimas actualizaciones: Si no encuentras tu problema con la búsqueda, explora los archivos del sitio o las listas filtradas de «últimas publicaciones». Muchas guías de resolución de problemas probadas con el tiempo quedan enterradas en contenido antiguo, y a veces una publicación reciente contiene la solución exacta para los nuevos cambios de autenticación en la plataforma de Microsoft.
• Combina filtros como un usuario avanzado: ¿Quieres ir más allá? Usa los sistemas de etiquetas o categorías junto con la búsqueda. Filtrar todas las publicaciones de «Azure AD» o acotar por «app registration» reducirá el tiempo de resolución de problemas y te permitirá descubrir problemas y soluciones que, de otro modo, se te habrían pasado por alto.