Comprender el error AADSTS70000 invalid grant en Microsoft Azure y Microsoft 365

By Mirko Peters · 2026-04-21

El error AADSTS70000 «invalid grant» es un dolor de cabeza habitual para administradores y desarrolladores que trabajan con Azure Active Directory y los servicios de Microsoft 365. Yo…

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

El error AADSTS70000 «invalid grant» es un dolor de cabeza habitual para administradores y desarrolladores que trabajan con Azure Active Directory y los servicios de Microsoft 365. Es frecuente verlo al conectar sistemas o automatizaciones a través de Power Platform, complementos de Outlook o aplicaciones que dependen de los flujos de identidad de Microsoft.

En pocas palabras, el error AADSTS70000 indica que algo falló durante la autenticación, normalmente cuando una aplicación o un usuario intenta obtener un token mediante OAuth, pero la «concesión» ya no es válida. Esto puede detener un flujo de trabajo de Power Automate, romper una integración con Outlook o interrumpir el inicio de sesión en cualquier aplicación que use Azure o Entra ID para la autenticación. Si trabajas en TI en la nube o en desarrollo de aplicaciones, conviene tomarse este error en serio, ya que señala problemas de autenticación y seguridad que pueden paralizar tus sistemas.

Saber cómo y dónde puede aparecer este error es esencial para solucionar problemas con rapidez y evitar esos momentos de desesperación en los que algo deja de funcionar de la noche a la mañana sin previo aviso.

Desglose de las partes del mensaje de error invalid grant 70000

Cuando te encuentres con el error AADSTS70000 invalid grant, en realidad estarás viendo dos partes clave del mensaje de error. La primera es el propio código de error: «AADSTS70000». Este código apunta específicamente a problemas con las concesiones de OAuth en el marco de autenticación de Microsoft.

La segunda parte es el motivo, normalmente identificado como «invalid_grant» o acompañado de un mensaje como «grant is invalid or malformed» (la concesión no es válida o está mal formada). Esto indica que el servidor no pudo aceptar la solicitud de token, normalmente por configuraciones incorrectas, directivas de seguridad o problemas con la estructura de la concesión.

Si ves este error en los registros de inicio de sesión de Azure, a veces incluirá detalles adicionales como «refresh token expired» (token de actualización caducado) o «redirect URI mismatch» (el URI de redirección no coincide). Aprender a reconocer estos patrones te ayuda a distinguir rápidamente entre errores del usuario, problemas en el registro de la aplicación y configuraciones incorrectas más profundas del servicio, lo que reduce el tiempo de diagnóstico y te lleva directamente a la documentación o a los canales de soporte de Microsoft más útiles.

¿Qué causa el error invalid grant 70000?

Estos son los motivos más habituales por los que puede aparecer el error AADSTS70000 invalid grant. Cada uno está relacionado con la forma en que OAuth y Azure AD gestionan los tokens, la seguridad y la configuración del registro de aplicaciones:

• Concesiones de OAuth mal formadas o caducadas: los tokens de acceso y de actualización no válidos o caducados son una causa principal. Si se usa un token después de su fecha de caducidad o si se manipula durante la transmisión, Azure AD lo rechaza de inmediato.
• URI de redirección incorrectos o configuración de cliente no coincidente: las diferencias mínimas en el URI de redirección registrado (incluso una barra diagonal que falte) pueden romper el flujo. Cambiar los datos de la aplicación sin actualizar la configuración de Azure AD es un responsable habitual.
• Problemas con los tokens de actualización: intentar reutilizar un token de actualización revocado, o usar uno caducado o emitido para otro cliente, provoca este error. A veces, los administradores rotan secretos o restablecen contraseñas e invalidan estos tokens sin darse cuenta.
• Interrupción por directivas de acceso condicional y MFA: si una regla de MFA o de cumplimiento del dispositivo se activa a mitad del flujo, especialmente en cuentas de servicio o en segundo plano, la concesión se deniega con poca explicación. Es un caso sutil que a menudo desconcierta incluso a profesionales con experiencia. ¿Necesitas profundizar en las directivas de acceso condicional y los problemas de confianza? Consulta este debate sobre las lagunas de las directivas y las mejores prácticas.
• Discrepancias en el consentimiento o los ámbitos: cuando los permisos se revocan, se consienten parcialmente o los ámbitos de las aplicaciones quedan obsoletos, las integraciones que funcionaban antes pueden fallar de repente. Los administradores y desarrolladores que integran aplicaciones de terceros deben verificar que los permisos necesarios y el consentimiento del administrador siguen vigentes. Para un análisis detallado del riesgo de consentimiento de OAuth en Entra ID, consulta esta página.

Rutas de solución para el error invalid grant 70000

1. Borra los tokens almacenados en caché y vuelve a autenticarte: La solución más rápida para los problemas de tokens o sesiones es desconectar y volver a conectar la cuenta o el servicio afectado. En Power Automate, Outlook y otras aplicaciones similares, cerrar sesión manualmente y volver a iniciarla puede forzar un nuevo flujo de OAuth y resolver los errores de concesión no válida.
2. Revisa y corrige los URI de redirección: Ve al Azure Portal y asegúrate de que el URI de redirección de tu registro de aplicaciones coincida exactamente con el que envía la aplicación o el conector. Incluso un carácter de más puede romper toda la autenticación cuando Azure valida la solicitud.
3. Valida el registro de aplicaciones y los secretos de cliente: Asegúrate de que los cambios recientes en el registro de aplicaciones, las rotaciones de secretos y los cambios de permisos estén actualizados. Los secretos de cliente caducados o que no coinciden son un enemigo silencioso de las integraciones en funcionamiento.
4. Revisa las directivas de acceso condicional y el consentimiento: Audita tus directivas de acceso condicional por si tienen exclusiones demasiado amplias o carencias en el cumplimiento de los dispositivos, ya que pueden interrumpir los flujos sin ningún mensaje de error evidente. Endurece los flujos de consentimiento de usuario y comprueba que el consentimiento de administrador siga aplicándose donde sea necesario. Para estrategias de gobernanza, consulta esta guía en profundidad sobre buenas prácticas de seguridad.
5. Actualiza los ámbitos de permisos: Revisa dos veces los ámbitos de permisos que solicita tu aplicación o automatización. A veces los ámbitos cambian de nombre o quedan obsoletos, sobre todo en Microsoft Graph. Asegúrate de que todo coincida entre el código de la aplicación, el registro en el portal y el historial de consentimientos.
6. Fuerza la eliminación de tokens tras los cambios de seguridad: Si los tokens pudieron verse comprometidos o acabas de actualizar las directivas de contraseñas, usa Intune o el Azure Portal para revocar todas las sesiones activas y pedir un nuevo inicio de sesión a todos los usuarios y automatizaciones. Si quieres saber más sobre cómo combatir los ataques de acceso persistente basados en consentimiento, lee esta guía sobre los riesgos de los ataques de consentimiento en Entra ID y cómo mitigarlos.

Problema de Power Automate: solución de problemas de fallos de autenticación por concesión no válida

1. Vuelve a conectar o actualiza las conexiones de datos afectadas: Si tu flujo muestra el error 70000, empieza por abrirlo en Power Automate, localizar las conexiones que muestren advertencias y volver a conectarlas. Así el servicio obtiene un token nuevo con las credenciales más recientes.
2. Comprueba los permisos del usuario y la validez de las credenciales: Asegúrate de que el usuario asignado al flujo tenga el acceso correcto al origen de datos. Si una cuenta usada en el flujo está deshabilitada, su contraseña ha caducado o han cambiado los requisitos de MFA, verás fallos de autenticación persistentes.
3. Valida los ámbitos de permisos necesarios: Revisa dos veces que los ámbitos concedidos coincidan con lo que necesita tu flujo para leer o enviar correos, crear archivos o agregar elementos a SharePoint. Esto es especialmente importante con los conectores de Outlook y Teams.
4. Revisa las directivas de DLP y las restricciones de conectores: Las directivas de prevención de pérdida de datos (DLP) pueden romper los flujos sin avisar si un conector pasa de desbloqueado a bloqueado o si los administradores lo reclasifican. Para más información sobre cómo crear automatizaciones estables con los límites de DLP adecuados, consulta esta guía de directivas DLP para desarrolladores de Power Platform.
5. Distingue los fallos transitorios de los persistentes: A veces el error 70000 se debe a interrupciones breves o fallos puntuales del servicio. Un fallo aislado seguido de una recuperación normalmente no es motivo de alarma, pero si el error persiste, empieza a revisar los permisos de conexión y los ámbitos de consentimiento en todo el inquilino.
6. Revisa la configuración de gobernanza: Las carencias en la gobernanza de entornos o de identidades pueden permitir que los riesgos de autenticación se cuelen con el tiempo. Para consejos sobre gobernanza de Power Platform, consulta este resumen de buenas prácticas.

Inicio de sesión en Azure 70000: uso de los registros de Azure AD y la auditoría para el diagnóstico

1. Empieza por los registros de inicio de sesión de Azure AD: Ve a los registros de inicio de sesión del Azure Portal y filtra los errores con el código «AADSTS70000». Revisa el motivo del error, la aplicación cliente y la IP de origen. Esto te ayuda a determinar si el problema está en el usuario, en la aplicación o en la configuración.
2. Analiza los patrones de comportamiento de tokens y clientes: Busca errores repetidos asociados al mismo usuario, entidad de servicio o aplicación. Los errores "invalid grant" constantes después de un evento programado (como la rotación de un secreto) suelen apuntar a directivas de token mal alineadas o a tokens de actualización caducados.
3. Usa los registros de auditoría de Azure AD para ver el contexto general: Combina los errores de inicio de sesión con los registros de auditoría de Azure AD. Así verás los cambios en los registros de aplicaciones, las actualizaciones de las directivas de acceso condicional y las posibles revocaciones masivas de tokens. Identificar un cambio justo antes de que empezaran los errores puede llevarte directamente a la causa raíz.
4. Aprovecha las herramientas de auditoría avanzada: Para investigaciones más amplias en Microsoft 365, herramientas como Microsoft Purview Audit ofrecen una retención ampliada y señales detalladas para el análisis forense. Aprende a configurar y usar estas herramientas en esta descripción general de Purview Audit.
5. Refuerza la gobernanza para una estabilidad a largo plazo: Una buena gobernanza ayuda a evitar roturas silenciosas y la deriva acumulativa de las directivas con el tiempo. Aplica barreras de protección con Azure Policy y supervisa las excepciones. Para una estrategia completa, consulta la guía de gobernanza empresarial de Azure.

Sincronización horaria y desfase del reloj: la causa oculta de los errores "invalid grant" de OAuth

Una de las causas más pasadas por alto de los errores AADSTS70000 "invalid grant" es el simple desajuste del reloj del sistema, conocido como desfase del reloj (clock skew). Cuando el equipo cliente y los servidores de Microsoft no coinciden en la hora actual, los tokens de OAuth y los códigos de autorización pueden parecer caducados o aún no válidos, aunque todo lo demás esté bien configurado.

Esto resulta especialmente complicado en entornos virtualizados o en la nube, donde distintos sistemas funcionan con relojes ligeramente desincronizados. Los retrasos de red o los modos de suspensión de los dispositivos pueden agravar el problema, haciendo que un intento de autenticación válido falle sin una causa aparente.

¿La solución? Sincroniza periódicamente todos los dispositivos con un servidor NTP fiable. Configura correcciones automáticas de hora en tus controladores de dominio, máquinas virtuales y dispositivos de usuario final. Mantenerte a un minuto o dos de la "hora real" es mucho mejor que lidiar con fallos de concesión misteriosos. Para una visión más amplia de los enfoques proactivos de seguridad en Microsoft 365 y Dynamics, incluidos los controles adaptativos, consulta este podcast sobre Zero Trust by Design.