Credenciais, OAuth2 e 2FA no n8n: guia de segurança

Os tipos de credenciais no n8n e o que cada um implica

O n8n agrupa as formas de autenticação em algumas categorias principais. Entender a diferença é o primeiro passo para protegê-las corretamente:

API Key (chave de API)

Uma string estática que identifica e autoriza sua aplicação. Exemplos: OpenAI API Key, Anthropic API Key, chave do CRM. São simples de configurar, mas têm um risco: se vazar, o atacante tem acesso permanente até você revogar manualmente. Boas práticas: rotação trimestral, escopos mínimos (não use a chave master quando existe uma chave de somente leitura), armazene em secrets manager.

OAuth2 (autorização delegada)

O protocolo usado por Google, Microsoft, Slack, GitHub e a maioria dos serviços modernos. Em vez de armazenar senha ou chave permanente, você armazena um token de acesso (curta duração) e um token de atualização. O n8n lida com a renovação automática. Vantagem: mesmo que o token vaze, ele expira em horas. Desvantagem: a configuração inicial é mais trabalhosa (registro do app no console do provedor).

Basic Auth (usuário + senha)

O formato mais simples e mais arriscado. Usuário e senha codificados em Base64 (que não é criptografia — é só codificação). Use apenas quando não há alternativa. Nunca use Basic Auth sobre HTTP não criptografado.

Header ou Query Parameter customizado

Algumas APIs usam cabeçalhos customizados (ex.: X-Api-Key) ou parâmetros na URL. O risco com query parameter é que a chave aparece nos logs de servidor e histórico do browser. Prefira sempre header.

Os 5 erros de segurança mais comuns que vejo em instalações n8n

Erro 1: credencial hardcoded no nó de código

Você escreve um nó de código JavaScript e coloca a API key diretamente na string: const apiKey = "sk-abc123...". Esse valor aparece no histórico de execuções, em backups, nos logs exportados — em qualquer lugar que o workflow seja copiado. Nunca faça isso. Sempre use credenciais configuradas pelo sistema de credenciais do n8n ou variáveis de ambiente.

Erro 2: uma credencial para tudo

Criar uma API key com acesso total e usá-la em todos os workflows. Se qualquer workflow for comprometido, o atacante tem acesso a tudo. O princípio correto é least privilege: cada workflow usa uma credencial com o mínimo de permissão necessária para aquela função específica.

Erro 3: n8n com acesso público sem autenticação

Subir o n8n e expor a porta 5678 diretamente na internet sem proteção. A interface de administração permite ver e executar qualquer workflow — se ela estiver pública, qualquer pessoa com a URL tem controle total. Sempre coloque o n8n atrás de um reverse proxy (Nginx, Caddy) com HTTPS e autenticação básica mínima, ou restrinja acesso por VPN/IP allowlist.

Erro 4: sem rotação de credenciais

Credenciais criadas na instalação inicial e nunca alteradas. Se a chave vazar (ex.: aparece em um repositório Git por acidente), você nem sabe e ela continua válida meses depois. Defina um calendário de rotação: API keys críticas a cada 90 dias, Basic Auth a cada 30 dias.

Erro 5: dados sensíveis no título das credenciais

Nomear uma credencial "Chave OpenAI produção - sk-abc123" expõe a chave parcialmente nos logs e na interface. Use nomes descritivos mas sem valores reais: "OpenAI - Produção - Workflows de Atendimento".

Integração com Vault e AWS Secrets Manager

Para empresas que já têm infraestrutura de secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), não faz sentido duplicar os segredos no banco do n8n. A abordagem correta é buscar o segredo dinamicamente no início do workflow.

Padrão de busca dinâmica de segredo

O fluxo funciona assim:

1. Workflow inicia (trigger de webhook, cron ou manual)
2. Nó HTTP Request faz chamada autenticada ao Vault API: GET /v1/secret/data/n8n/openai
3. Nó de código extrai o valor do campo data.data.api_key
4. Valor é armazenado em variável de contexto do workflow
5. Nós subsequentes usam essa variável — nunca o valor hardcoded

Isso garante que quando você rotaciona a chave no Vault, todos os workflows automaticamente usam a nova chave na próxima execução. Sem precisar atualizar nada no n8n.

Autenticação do n8n no Vault: use AppRole authentication — o n8n tem um role_id e secret_id estáticos que permitem buscar segredos, mas não criar ou deletar. O token de acesso gerado tem TTL de 1 hora e é renovado automaticamente. Essa credencial de acesso ao Vault (e somente ela) fica armazenada como variável de ambiente do processo n8n.

AWS Secrets Manager

A integração com AWS é similar. O n8n roda com uma IAM Role que tem permissão apenas de secretsmanager:GetSecretValue para os ARNs específicos que ele precisa acessar. Nenhuma permissão de criação, listagem ou exclusão. Isso implementa least privilege em nível de cloud provider.

Configurando OAuth2 corretamente no n8n

OAuth2 é o padrão para integrar com Google Workspace, Microsoft 365, Slack, HubSpot e dezenas de outros serviços. A configuração no n8n segue sempre o mesmo padrão, mas tem detalhes que causam confusão:

Passo 1: registrar o app no provedor

Acesse o console de desenvolvedor do serviço (Google Cloud Console, Azure App Registration, Slack API) e crie um novo aplicativo. Você vai precisar fornecer a URL de callback do n8n: https://seu-n8n.dominio.com/rest/oauth2-credential/callback. Anote o Client ID e Client Secret gerados.

Passo 2: escopos mínimos necessários

Na configuração do app no provedor, defina apenas os escopos (permissões) que o workflow realmente precisa. Se o workflow só lê e-mails, não peça permissão de envio. Se ele só lista tarefas, não peça permissão de criação. Escopos mínimos limitam o impacto de um token comprometido.

Passo 3: armazenar Client Secret com segurança

O Client Secret é como a senha do seu app OAuth2. Ele fica armazenado no banco do n8n criptografado com AES-256. Para garantir isso, confirme que a variável N8N_ENCRYPTION_KEY está configurada com uma chave forte (pelo menos 32 caracteres aleatórios) e armazenada no seu secrets manager, não no arquivo .env em disco.

Tokens de acesso vs. refresh tokens

OAuth2 gera dois tokens: o access token (válido por 1–60 minutos) e o refresh token (válido por dias ou semanas). O n8n usa o refresh token para renovar o access token automaticamente. Se o refresh token expirar ou for revogado, o workflow falha na próxima execução — você precisa re-autorizar manualmente. Configure alertas para esse tipo de falha de autenticação.

2FA no painel admin do n8n

A partir da versão 1.x, o n8n suporta autenticação de dois fatores (2FA) para o login no painel administrativo. Isso é especialmente importante se o painel estiver acessível pela internet.

Para habilitar 2FA: vá em Settings → Users → clique no seu usuário → Enable Two-Factor Authentication. O n8n vai gerar um QR code para você escanear com um app autenticador (Google Authenticator, Authy, 1Password). A partir daí, o login exige a senha + o código de 6 dígitos.

Contas de serviço: se você tem usuários de automação (bots que acessam a API do n8n), crie contas separadas com API tokens em vez de usuário + senha. Essas contas não precisam de 2FA (não é interativo), mas devem ter permissões mínimas (somente execução de workflows específicos, sem acesso à configuração).

SSO (Single Sign-On): a versão Enterprise do n8n suporta SAML/OIDC para integrar com seu IdP corporativo (Okta, Azure AD, Google Workspace). Para PMEs sem IdP próprio, 2FA nativo resolve.

Checklist de segurança de credenciais: 15 itens

Use esta lista como critério de auditoria da sua instalação n8n. Toda instalação em produção que processa dados de clientes deve passar em todos os itens de criticidade Alta.

Credenciais e LGPD: o que você precisa saber

O n8n frequentemente processa dados pessoais: nomes, e-mails, telefones, histórico de compras. A LGPD exige que você implemente medidas de segurança "adequadas" para proteger esses dados. As práticas deste artigo são exatamente essas medidas.

Dois pontos específicos que valem atenção: (1) o princípio da minimização — o n8n só deve ter acesso aos dados que precisa, não ao banco inteiro de clientes; (2) o registro de operações — você deve conseguir demonstrar quem acessou quais dados, quando e com qual finalidade. Os logs de execução do n8n, se configurados corretamente, servem como evidência.

Para aprofundar, veja o artigo LGPD em aplicações LLM e o guia sobre guardrails em aplicações de IA.

Conclusão: segurança de credenciais não é paranoia — é operação básica

Uma instalação n8n não segura é um risco real. Em 2024, vários casos de exposição de credenciais em plataformas de automação resultaram em cobranças de dezenas de milhares de dólares em APIs de LLM (o atacante usa sua chave para rodar seus próprios modelos às suas custas). Sem contar o risco de vazamento de dados de clientes.

O checklist de 15 itens deste artigo não exige orçamento extra nem consultoria especializada. É configuração e disciplina. Implante agora e revise trimestralmente.