Estoy ejecutando múltiples instancias de n8n (dev / rec / prod) y utilizando credenciales de Microsoft Entra ID para consultar Microsoft Graph (listar chats por userId, miembros del chat, etc.).
Cuando despliego un flujo de trabajo desde n8n-dev a n8n-rec, el flujo de trabajo falla sistemáticamente en la primera ejecución programada con: “refreshToken is required” / ERR_ASSERTION.
La única forma de recuperarse es abrir manualmente la credencial y hacer clic en “Reconectar” en la instancia de destino. Después de algunas horas o el siguiente despliegue, el problema vuelve a aparecer.
Sospecho que esto es la combinación de tres comportamientos conocidos, pero me gustaría una confirmación del equipo de n8n y orientación sobre mejores prácticas para una configuración multi-entorno.
Qué creo que está pasando
-
Las credenciales no se transfieren con las exportaciones de flujos de trabajo. El JSON del flujo de trabajo solo contiene una referencia de credencial (id + nombre), no el blob de token cifrado. Este es el comportamiento esperado.
-
Source Control & Environments excluye explícitamente las credenciales. Según la documentación oficial ( External secrets | n8n Docs ): “La función no admite el uso de diferentes credenciales en diferentes instancias.”
-
Microsoft Entra utiliza rotación de tokens de actualización. Cada llamada de actualización invalida el refresh_token anterior e emite uno nuevo. Por lo tanto, si el mismo registro de credencial existe en dos instancias (dev + rec), cualquiera que sea la instancia que se actualice primero quema el token del otro, lo que resulta en “refreshToken is required” en la segunda. Esto está documentado en el problema #26453 ( Microsoft Outlook OAuth2 token refresh fails after ~1 hour on n8n Cloud, masked by dummy.stack.replace error · Issue #26453 · n8n-io/n8n · GitHub ): “Microsoft Entra ID reemplaza los tokens de actualización con un token nuevo en cada uso. Si n8n no guarda el nuevo token de actualización, los intentos de actualización posteriores pueden fallar.” También se reproduce en el nodo Entra ID específicamente en el hilo de la comunidad #193787 ( Entra ID node reconnection issues ) y el problema #14426 (Microsoft Entra Component auth failure. · Issue #14426 · n8n-io/n8n · GitHub).
El nodo es un nodo HTTP Request que apunta a https://graph.microsoft.com/v1.0/users/{id}/chats con un tipo de credencial predefinida de Microsoft Entra ID (Azure Active Directory).
Flujo de trabajo
ENTRADA DE FLUJO DE TRABAJO → LISTAR CHAT POR USERID (HTTP Request, Graph API, falla aquí) → DIVIDIR VALOR DE LISTA → RECORRER CHATS → FILTRAR CHAT POR TEMA → si verdadero: OBTENER MIEMBROS DEL CHAT → INFORMACIÓN DE USUARIOS / si falso: NOMBRE DE CHAT FUERA DE TEMA → FIN DEL BUCLE.
¡Bienvenido @Rodolphe24 a nuestra comunidad! Soy Jay y soy un creador verificado de n8n.
Tu análisis de causa raíz es exactamente correcto. Microsoft Entra ID utiliza rotación de tokens de actualización, por lo que el entorno que llama primero al endpoint de token invalida el token en el otro. La solución es tratar cada entorno como una aplicación OAuth completamente separada: crea un Registro de aplicación distinto en Azure para dev y otro para rec, cada uno con su propio Client ID/Secret y su propio redirect URI apuntando a la instancia de n8n de ese entorno. Nunca compartas el mismo registro de credenciales entre instancias. Una vez que lo hayas configurado, cada entorno gestiona su propio ciclo de actualización de forma independiente y la invalidación de tokens se detiene.
buenos días @Rodolphe24
también evitaría promover workflows esperando que la credencial vaya junto. Lo que suelo hacer en estos escenarios es mantener el mismo nombre lógico de la credencial en dev/rec/prod, pero reconectar/crear la credencial localmente en cada instancia, usando el App Registration de ese entorno. Así el workflow sigue siendo fácil de promover vía Source Control, pero cada entorno mantiene su propio estado OAuth y su propio ciclo de refresh token. También vale revisar si el workflow importado está apuntando a la credencial correcta en el entorno de destino después del pull/deploy.
Gracias por el aporte — en realidad ese es el patrón que ya estoy utilizando:
-
Mismo nombre de credencial lógico en dev/rec/prod
-
Registro de aplicación de Azure separado por entorno
-
Cada credencial reconectada localmente en su propia instancia
Después del despliegue, el flujo de trabajo apunta a la credencial correcta en el destino. Antes de publicar el flujo de trabajo ya lo había ejecutado con éxito. Por eso no entiendo…
@Rodolphe24
Investigaría dos cosas: si la credencial realmente está recibiendo un refresh token en el momento de la reconexión, especialmente con offline_access/admin consent correcto, y si todos los containers/workers de la misma instancia usan la misma N8N_ENCRYPTION_KEY.
Hola, gracias por tu comentario. ¿Podría estar relacionado con un problema con un worker de n8n? Cuando ejecuto el flujo de trabajo manualmente, funciona correctamente. Sin embargo, cuando activo el flujo de trabajo principal usando un nodo de planificador después de publicarlo, recibo un error de token de actualización.
Sí, esto casi con certeza es un problema de worker. Cuando un flujo de trabajo programado se ejecuta a través de un worker, el worker necesita exactamente la misma N8N_ENCRYPTION_KEY que la instancia principal para descifrar las credenciales almacenadas. Si difieren, el descifrado del token falla y obtienes un error de token de actualización. Verifica las variables de entorno de tu worker y confirma que N8N_ENCRYPTION_KEY coincida con la instancia principal. También asegúrate de que el worker tenga acceso a la misma base de datos donde se almacenan las credenciales - un worker conectado a una BD diferente no verá el token en absoluto.
Observación sobre el error refreshToken
Realicé varias pruebas relacionadas con el error refreshToken is required:
-
Prueba 1:
En la instancia n8n-rec con permisos de solo lectura, al iniciar el flujo de trabajo falla con el siguiente error:
refreshToken is required
-
Prueba 2:
En la instancia n8n-rec con permisos de lectura/escritura, al iniciar el flujo de trabajo se produce el mismo error:
refreshToken is required
-
Prueba 3:
Después de reconectar manualmente Microsoft Entra ID en la instancia n8n-rec con permisos de lectura/escritura, el flujo de trabajo se inicia correctamente sin ningún error.
El error nunca aparece en la instancia n8n-dev con permisos de lectura/escritura, flujos de trabajo publicados.
@Rodolphe24 Excelente desglose de pruebas. Tu resultado en Test 3 tiene sentido — cuando reconectas manualmente la credencial en n8n-rec, Microsoft emite un token OAuth nuevo que incluye el alcance offline_access (necesario para el token de actualización). La credencial antigua almacenada en n8n-rec probablemente tenía un token expirado o con alcances limitados de cuando se configuró originalmente.
La conclusión clave: si reconectar en n8n-rec con lectura/escritura funciona, la credencial original carecía del alcance offline_access. Para evitar que esto se repita, asegúrate de que tu Registro de Aplicación de Azure tenga ese alcance habilitado y reautoriza en cada instancia por separado.
- Crea registros de aplicación separados en Azure: uno para Dev, otro para Rec y otro para Prod.
- Inyecta tu configuración de cliente en tus diferentes instancias del servidor n8n utilizando variables de entorno estándar:
MICROSOFT_CLIENT_IDMICROSOFT_CLIENT_SECRETMICROSOFT_TENANT_ID
- En tu nodo HTTP Request, cambia el tipo de autenticación a Generic Credential Type → OAuth2.
- En los campos de configuración de credenciales, utiliza expresiones de n8n para hacer referencia a tus variables de entorno:
- Client ID:
{{$env.MICROSOFT_CLIENT_ID}}
- Client Secret:
{{$env.MICROSOFT_CLIENT_SECRET}}
Como n8n evalúa las variables de entorno de forma nativa por instancia, tu JSON de flujo de trabajo sigue siendo idéntico en Dev, Rec y Prod, pero cada instancia se comunica con su propio contenedor de Azure aislado.
Házme saber si esto funciona para ti, sino tengo otra solución.
Ok, gracias por tu comentario, voy a probar eso.
Hola, gracias por tu comentario, no es posible porque tengo que usar la autenticación específica basada en Microsoft Graph: Microsoft Entra ID (Azure Active Directory) API que también está basada en oauth2
¡Me alegra saber que mi respuesta fue útil y se seleccionó como la solución! ¡Eso realmente me hizo el día!
Si tienes más preguntas sobre este tema (u otras configuraciones de n8n), no dudes en contactarme, estaré feliz de profundizar más.
@Rodolphe24
Después del deploy, antes de hacer clic en «Reconnect», ¿la credencial REC aún contiene un estado OAuth válido y es la misma credencial utilizada por la ejecución programada?
Si es posible, por favor comparta el método de deploy, la arquitectura del rec (instancia única o modo queue/workers/múltiples contenedores), la evidencia antes del reconnect, log completo de la primera ejecución programada después del deploy.
