Configurar uma automação que liga o n8n ao Google deveria ser um processo linear. Mas muitos responsáveis de PME deparam-se com uma janela que devolve apenas “Unauthorized” e a integração fica parada. O erro OAuth2 n8n callback não é um capricho técnico — é uma barreira real que impede a empresa de poupar horas de trabalho manual.
Uma falha identificada na comunidade n8n, em instalações self-hosted com Docker Swarm e proxy Traefik, mostra que o problema está num pormenor aparentemente invisível: o cookie de sessão não é enviado no redireccionamento do Google. E a correcção, felizmente, não exige reescrever código — apenas um ajuste na configuração do proxy.
O que é e como funciona o callback OAuth2 no n8n
Quando liga o n8n a uma conta Google — para ler emails, gerir calendários ou aceder ao YouTube — o fluxo de autenticação segue três passos. Primeiro, o n8n gera um URL que o envia para o ecrã de consentimento do Google. Depois de autorizar, o Google redirecciona o seu browser de volta para um endereço específico do n8n, com um código de acesso. Esse endereço é o callback. Por fim, o n8n troca esse código por um token que fica guardado na credencial.
O problema surge exactamente no redireccionamento. O n8n precisa de confirmar que o utilizador que iniciou o processo é o mesmo que está a receber o callback. Para isso, guarda um cookie de sessão — o n8n-auth — no browser. Mas, em ambientes com proxy reverso (como Traefik) e Cloudflare, esse cookie pode não ser reenviado. O resultado: o n8n não reconhece o utilizador, a verificação falha e o ecrã mostra o genérico “Unauthorized”.
A causa está no ficheiro oauth.service.ts do n8n, onde o estado CSRF é descodificado e comparado com o ID do utilizador da sessão. Se o cookie não chega, o utilizador é undefined e a autenticação é recusada. Não é um bug do Google, nem uma falha de segurança — é uma questão de configuração de rede.
O que diferencia esta solução das alternativas
Até agora, a recomendação mais comum para erros de autenticação OAuth2 no n8n era “verifique as variáveis de ambiente”. Muitos administradores reviam o N8N_HOST, o protocolo e o WEBHOOK_URL, mas o erro persistia. Outros suspeitavam de conflitos com o Cloudflare ou com o proxy, mas faltava uma explicação precisa.
A identificação da causa raiz — a ausência do cookie n8n-auth no redireccionamento — muda a abordagem. Em vez de tentar adivinhar, o gestor técnico pode agir directamente sobre o proxy: garantir que o domínio do cookie está correcto, que o atributo SameSite não bloqueia o envio e que o Traefik (ou outro proxy) não está a remover cabeçalhos essenciais. É uma correcção cirúrgica, que resolve o problema de uma vez, sem depender de workarounds frágeis.
Para PMEs que usam n8n em Docker Swarm, a diferença é prática: a integração com Google volta a funcionar sem necessidade de migrar para a cloud ou de adoptar outro software de automação. Basta um ajuste na configuração existente.
O que isto significa para PMEs portuguesas
Uma PME que utiliza n8n para automatizar relatórios, sincronizar contactos ou publicar vídeos depende de ligações OAuth2 estáveis. Quando o callback falha, o trabalho manual regressa — e com ele os erros, os atrasos e a frustração da equipa. Este erro, em particular, afecta instalações self-hosted, que são comuns em empresas que querem manter o controlo dos dados e evitar custos de subscrição.
Corrigir o problema significa retomar a automatização em minutos, não em dias. E o custo é essencialmente zero: não há licenças adicionais, apenas a intervenção de um perfil técnico que compreenda a configuração do proxy. Para empresas com 5 a 50 colaboradores, onde o tempo do responsável de marketing ou operações é escasso, essa fiabilidade traduz-se directamente em produtividade. Se a sua empresa já investiu em soluções de inteligência artificial para acelerar processos, garantir que as automações base não falham é o primeiro passo para extrair valor real.
Além disso, a resolução documentada na comunidade n8n serve de alerta: ambientes com Cloudflare e proxy exigem atenção redobrada aos cookies. Ignorar este detalhe pode bloquear não só o Google, mas qualquer serviço que dependa de OAuth2 — e isso inclui Microsoft, LinkedIn e muitas outras APIs essenciais para o dia-a-dia de uma PME.
O erro que a maioria comete
A maioria das empresas, ao ver o erro “Unauthorized”, assume que o problema está nas credenciais do Google. Revêem o Client ID, o segredo, as permissões da API — e nada resolve. O verdadeiro culpado está na infra-estrutura: o cookie de sessão não chega ao destino. Insistir na consola do Google Cloud é perder tempo. O diagnóstico correcto passa por inspeccionar o tráfego de rede e verificar se o cookie n8n-auth está presente no pedido de callback. Sem isso, qualquer tentativa de correcção é um tiro no escuro.
Riscos e limitações
A solução exige acesso à configuração do proxy e conhecimentos de redes. Não é um clique num botão. Se a sua empresa não tem um perfil técnico interno, pode precisar de apoio externo. Além disso, a correcção documentada aplica-se a ambientes com Traefik e Docker Swarm; se usar outro proxy (como Nginx ou Caddy), os detalhes podem variar. Há também o risco de, ao ajustar o SameSite ou o domínio do cookie, afectar outras aplicações que partilham o mesmo proxy. Por fim, esta falha é específica da versão 2.29.8 do n8n — versões futuras podem trazer alterações que exijam nova adaptação.
Veredito Descomplicar®
O erro OAuth2 n8n callback é um daqueles obstáculos técnicos que parecem complexos mas têm uma causa simples. Vale a pena resolvê-lo se a sua empresa já utiliza n8n self-hosted e depende de integrações Google — o retorno em horas poupadas é imediato. Se está a começar agora com automação, talvez compense avaliar se uma instalação cloud do n8n (onde este problema não ocorre) não será mais prática. Em qualquer caso, não deixe que um cookie bloqueie a eficiência operacional. Para um diagnóstico completo do seu ambiente de automação, a consultoria estratégica Descomplicar® pode identificar pontos cegos antes que eles travem o negócio.