O que é API Key (na prática de automação)
API Key é uma credencial estática (uma “chave” ou token) usada para identificar quem está chamando uma API. Em automações, ela normalmente fica guardada nas credenciais do orquestrador e é enviada em um header (por exemplo, Authorization) ou como parâmetro.
Funciona bem quando o serviço foi desenhado para integração simples e quando você controla bem onde a chave fica armazenada. O problema é que, por ser estática, ela vira um “cartão mestre”: vazou, qualquer um usa até você revogar e trocar.
O que é OAuth 2.0 (e por que ele é mais “chato”, porém mais seguro)
OAuth 2.0 é um conjunto de fluxos para delegar acesso: em vez de você guardar a senha do usuário, você recebe um token com permissões (escopos) e prazo (expiração). Em automações, isso é comum para conectar Gmail/Google Drive, Microsoft 365, CRMs e ferramentas de anúncios.
Na vida real, o ganho é governança: você limita escopos, consegue revogar acesso sem “quebrar tudo”, e pode usar refresh tokens para manter a automação rodando sem reautenticar toda hora. A parte “chata” é justamente configurar redirecionamento, consentimento, escopos e tratar expiração.
Tabela rápida: OAuth 2.0 vs API Key
Não existe “melhor absoluto”. Existe o que te dá menos risco e menos retrabalho para o seu cenário.
| Critério | OAuth 2.0 | API Key |
|---|---|---|
| Escopos/permissões | Sim, normalmente bem granular | Geralmente não; depende do provedor |
| Expiração de token | Sim (access token expira; pode haver refresh) | Em geral não expira (ou expira raramente) |
| Revogação | Boa: revoga por app/usuário | Possível, mas costuma ser “trocar a chave” e atualizar tudo |
| Complexidade de setup | Maior (redirect URI, consentimento, refresh) | Menor (copiar/colar chave) |
| Risco em caso de vazamento | Menor se escopos forem mínimos e tokens expirarem | Maior: uma chave vazada pode dar acesso amplo por tempo indefinido |
| Melhor para | Apps multiusuário, integrações com Google/Microsoft/CRMs | Serviço-a-serviço simples, integrações internas, APIs legadas |
Erros comuns que quebram automações (e como evitar)
Aqui é onde a maioria das equipes se enrola: não é a API, é a operação do acesso.
Como decidir em 60 segundos (perguntas que resolvem)
Se você responder “sim” para as perguntas 1 ou 2, você quase sempre cai em OAuth. Se todas forem “não”, API Key pode ser o caminho pragmático.
Perguntas frequentes
OAuth 2.0 é mais seguro do que API Key?
API Key pode ser usada com segurança em automações?
Por que minha automação para de funcionar do nada quando uso OAuth?
Webhook precisa de OAuth ou API Key?
Termos relacionados
Como gerenciar secrets e credenciais no n8n self-hosted (sem vazar dados e sem dor)
Aprenda como organizar, proteger e rotacionar secrets e credenciais no n8n self-hosted: variáveis de ambiente, criptografia, permissões, logs, backups e checklist de produção.
Ler →
Como validar assinatura HMAC em webhook no n8n (e evitar requisição falsificada)
Guia prático para validar assinatura HMAC (SHA-256) em webhooks no n8n, rejeitar requests falsificadas e proteger automações com secret e timestamp.
Ler →
Webhook ou polling em automações: como escolher (sem perder eventos e sem estourar limites)
Guia direto para decidir entre webhook e polling: latência, confiabilidade, custo por execução, rate limit e como evitar duplicidades. Inclui tabela e checklist prático.
Ler →
Como evitar replay attack em webhooks: timestamp, nonce e idempotência (na prática)
Guia prático para proteger webhooks contra replay attack usando timestamp, nonce, verificação de assinatura e idempotência. Com passos, checklist e exemplos de decisões para automações (n8n/Make/Zapier).
Ler →