Estou executando múltiplas instâncias do n8n (dev / rec / prod) e usando credenciais do Microsoft Entra ID para consultar o Microsoft Graph (listar chats por userId, membros do chat, etc.).
Quando faço deploy de um workflow do n8n-dev para o n8n-rec, o workflow falha sistematicamente na primeira execução agendada com: “refreshToken is required” / ERR_ASSERTION.
A única forma de recuperar é abrir manualmente a credencial e clicar em “Reconectar” na instância de destino. Após algumas horas ou no próximo deploy, o problema volta.
Suspeito que seja a combinação de três comportamentos conhecidos, mas gostaria de confirmação do time do n8n e orientações de melhores práticas para uma configuração multi-ambiente.
O que acho que está acontecendo
-
As credenciais não são transferidas com as exportações de workflow. O JSON do workflow contém apenas uma referência da credencial (id + name), não o blob de token criptografado. Este é o comportamento esperado.
-
O Source Control & Environments explicitamente exclui credenciais. De acordo com a documentação oficial (External secrets | n8n Docs): “O recurso não suporta usar diferentes credenciais em diferentes instâncias.”
-
O Microsoft Entra usa rotação de refresh token. Cada chamada de refresh invalida o refresh_token anterior e emite um novo. Então, se o mesmo registro de credencial existe em duas instâncias (dev + rec), qualquer que seja a instância que fazer refresh primeiro queima o token da outra, resultando em “refreshToken is required” na segunda. Isso está documentado na issue #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): “O Microsoft Entra ID substitui refresh tokens com um token novo a cada uso. Se o n8n não salvar o novo refresh token, tentativas subsequentes de refresh podem falhar.” Também é reproduzido no node do Entra ID especificamente no tópico comunitário #193787 (Entra ID node reconnection issues) e na issue #14426 (Microsoft Entra Component auth failure. · Issue #14426 · n8n-io/n8n · GitHub).
O node é um node HTTP Request apontando para https://graph.microsoft.com/v1.0/users/{id}/chats com um tipo de credencial predefinida Microsoft Entra ID (Azure Active Directory) API.
Workflow
ENTRADA DO WORKFLOW → LIST CHAT BY USERID (HTTP Request, Graph API, falha aqui) → SPLIT OUT LIST VALUE → LOOP OVER CHATS → FILTER CHAT BY TOPIC → if true: GET CHAT MEMBERS → USERS INFOS / if false: OFF TOPIC CHAT NAME → END OF LOOP.
Bem-vindo @Rodolphe24 à nossa comunidade! Sou Jay e sou um criador verificado da n8n.
Sua análise de causa raiz está exatamente correta. Microsoft Entra ID usa rotação de token de atualização, então qualquer ambiente que chame o endpoint de token primeiro invalida o token no outro. A solução é tratar cada ambiente como um aplicativo OAuth completamente separado - crie um App Registration distinto no Azure para dev e outro para rec, cada um com seu próprio Client ID/Secret e seu próprio redirect URI apontando para a instância n8n daquele ambiente. Nunca compartilhe o mesmo registro de credencial entre instâncias. Depois de configurar isso, cada ambiente gerencia seu próprio ciclo de atualização independentemente e a invalidação de token para.
bom dia @Rodolphe24
eu também evitaria promover workflows esperando que a credencial vá junto. O que costumo fazer nesses cenários é manter o mesmo nome lógico da credencial em dev/rec/prod, mas reconectar/criar a credencial localmente em cada instância, usando o App Registration daquele ambiente. Assim o workflow continua fácil de promover via Source Control, mas cada ambiente mantém seu próprio estado OAuth e seu próprio ciclo de refresh token. Também vale revisar se o workflow importado está apontando para a credencial correta no ambiente de destino depois do pull/deploy.
Obrigado pelo feedback — esse é na verdade o padrão que já estou usando:
-
Nome de credencial lógico idêntico entre dev/rec/prod
-
Registro do Azure App separado por ambiente
-
Cada credencial reconectada localmente em sua própria instância
Após o deploy, o workflow aponta para a credencial correta no destino. Eu já tinha lançado o workflow com sucesso antes de publicar. Por isso não consigo entender…
@Rodolphe24
Eu investigaria duas coisas: se a credencial realmente está recebendo um refresh token no momento da reconexão, especialmente com offline_access/admin consent correto, e se todos os containers/workers da mesma instância usam o mesmo N8N_ENCRYPTION_KEY.
Oi, obrigado pelo feedback. Isso poderia estar relacionado a um problema com um worker do n8n? Quando executo o fluxo manualmente, funciona corretamente. Porém, quando aciono o fluxo principal usando um nó de agendador após publicá-lo, encontro um erro de token de atualização.
Sim, isso é quase certamente um problema de worker. Quando um fluxo de trabalho agendado é executado via um worker, o worker precisa ter a mesma N8N_ENCRYPTION_KEY que a instância principal para descriptografar credenciais armazenadas. Se forem diferentes, a descriptografia do token falha e você recebe um erro de refresh token. Verifique as variáveis de ambiente do seu worker e confirme que N8N_ENCRYPTION_KEY corresponde à instância principal. Também certifique-se de que o worker tem acesso ao mesmo banco de dados onde as credenciais são armazenadas - um worker conectado a um BD diferente não verá o token.
Observação sobre o erro refreshToken
Realizei vários testes relacionados ao erro refreshToken is required:
-
Teste 1:
Na instância n8n-rec com permissões de somente leitura, o lançamento do workflow falha com o seguinte erro:
refreshToken is required
-
Teste 2:
Na instância n8n-rec com permissões de leitura/escrita, o lançamento do workflow produz o mesmo erro:
refreshToken is required
-
Teste 3:
Após reconectar manualmente o Microsoft Entra ID na instância n8n-rec com permissões de leitura/escrita, o workflow é lançado com sucesso sem nenhum erro.
O erro nunca ocorre na instância n8n-dev com permissões de leitura/escrita, workflows publicados.
@Rodolphe24 Ótimo detalhamento do teste. Seu resultado no Teste 3 faz sentido — quando você reconecta manualmente a credencial no n8n-rec, a Microsoft emite um novo token OAuth que inclui o escopo offline_access (necessário para o refresh token). A credencial antiga armazenada no n8n-rec provavelmente tinha um token expirado ou com escopos limitados de quando foi configurada pela primeira vez.
O ponto-chave: se reconectar no n8n-rec com permissões de leitura/escrita funciona, a credencial original estava sem o escopo offline_access. Para evitar que isso se repita, certifique-se de que seu Azure App Registration tem esse escopo habilitado e reautorize em cada instância separadamente.
- Crie registros de aplicativo separados no Azure: um para Dev, um para Rec, um para Prod.
- Injete sua configuração de cliente em suas diferentes instâncias de servidor n8n usando variáveis de ambiente padrão:
MICROSOFT_CLIENT_IDMICROSOFT_CLIENT_SECRETMICROSOFT_TENANT_ID
- No seu nó HTTP Request, mude o tipo de Autenticação para Generic Credential Type → OAuth2.
- Nos campos de configuração de credencial, use expressões n8n para referenciar suas variáveis de ambiente:
- Client ID:
{{$env.MICROSOFT_CLIENT_ID}}
- Client Secret:
{{$env.MICROSOFT_CLIENT_SECRET}}
Porque o n8n avalia variáveis de ambiente nativamente por instância, seu workflow JSON permanece idêntico em Dev, Rec e Prod, mas cada instância se comunica com seu próprio contêiner Azure isolado.
Me avise se isso funciona para você, senão tenho outra solução.
ok, obrigado pelo feedback, vou testar isso.
Olá, obrigado pelo seu feedback, não é possível porque preciso usar a autenticação específica baseada no Microsoft Graph: Microsoft Entra ID (Azure Active Directory) API que também é baseada em oauth2
Fico feliz em saber que minha resposta foi útil e foi selecionada como solução – isso realmente fez meu dia!
Se você tiver mais dúvidas sobre este tópico (ou outras configurações de n8n), não hesite em me chamar, fico feliz em me aprofundar mais.
@Rodolphe24
Depois do deploy, antes de clicar em “Reconnect”, a credencial REC ainda contém um estado OAuth válido e é a mesma credencial usada pela execução agendada?
se for possível por favor compartilhe o método de deploy, a arquitetura do rec (single instance ou queue mode/workers/múltiplos containers), a evidência antes do reconnect, log completo da primeira execução agendada após o deploy.
Oi pessoal,
Desculpem a demora na resposta, ando bastante ocupado ultimamente.
Só pra fechar esse assunto: depois de atualizar o n8n por várias versões mais recentes, o problema com o refresh token que a gente tava tendo na transferência de workflows do nosso ambiente n8n-dev para o n8n-rec parece ter desaparecido.
A gente não conseguiu reproduzir o problema desde as atualizações, então parece que pode ter sido corrigido em uma das versões mais novas.
Obrigado a todos pela ajuda e pelos insights ao longo dessa discussão.
Abraços
