OAuth gerenciado vs OAuth genérico para Gmail REST (HTTP Request) – Qual abordagem para produção?

Perguntas
1

Olá a todos,
Estou construindo um agente de email em produção com o n8n Cloud e gostaria de receber feedback de pessoas que já implantaram integrações do Gmail em larga escala.
Arquitetura atual
Não estou usando o nó do Gmail.
Em vez disso, estou usando:
Nós HTTP Request
Gmail REST API
Credencial genérica do Google OAuth2
Apenas um escopo:
https://www.googleapis.com/auth/gmail.modify
O fluxo de trabalho executa:
listar mensagens não lidas
obter mensagem
criar rascunho
enviar mensagem
marcar como lida
Tudo funciona corretamente.
Por que evitei o nó do Gmail
Pelo que entendo, o nó do Gmail solicita vários escopos fixos, incluindo:

gmail.modify
gmail.compose
etc.
Queria seguir o princípio do menor privilégio e solicitar apenas gmail.modify.
Por isso, mudei para HTTP Request + Generic OAuth2.
Minha pergunta sobre Managed OAuth
Agora estou avaliando o Managed OAuth disponível no n8n Cloud.
A documentação explica que simplifica a autenticação, mas não consegui encontrar detalhes técnicos sobre o que realmente acontece nos bastidores.
Gostaria de saber:
O Managed OAuth usa internamente a mesma credencial do Gmail (mesmos escopos) que o nó do Gmail?
Se eu criar uma credencial do Gmail com Managed OAuth, posso usá-la dentro de nós HTTP Request?
Durante o consentimento do Google, quais escopos são realmente solicitados?
Existe alguma forma de limitar o Managed OAuth apenas para:
gmail.modify
em vez de todos os escopos do Gmail?
Alguém já implantou com sucesso um fluxo de trabalho de produção com REST do Gmail usando Managed OAuth em vez de uma credencial OAuth genérica?
Verificação do Google
Uma coisa que também estou tentando entender:
O Managed OAuth muda algo em relação aos requisitos de verificação do OAuth do Google (escopos restritos, avaliação de segurança, etc.)?
Não estou pedindo aconselhamento jurídico, apenas me perguntando se alguém tem experiência real em produção com isso.
Qualquer feedback ou experiência em produção seria muito apreciado.
Obrigado!

Descreva o problema/erro/pergunta

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu fluxo de trabalho

(Selecione os nós em sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração do n8n

  • Versão do n8n: cloud
  • Banco de dados (padrão: SQLite):
  • Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
  • Executando o n8n via (Docker, npm, n8n cloud, aplicativo desktop): cloud
  • Sistema operacional:
2

Oi @Jidenkaes

Sua configuração existente — OAuth2 genérico + HTTP Request + escopo único gmail.modify — é a escolha certa para um agente do Gmail em produção onde o princípio do menor privilégio importa. OAuth gerenciado não foi projetado para customização de escopo ou uso do nó HTTP Request, e mudar para ele provavelmente expandiria sua superfície de escopo, não reduziria. Mantenha sua arquitetura atual e publique seu app GCP como Interno (se dentro de um Google Workspace) para evitar completamente a exigência de verificação pública.

Isso deve lhe dar um quadro mais claro

image
image718×275 5.47 KB

3

Oi @Jidenkaes
OAuth gerenciado é a mesma credencial Gmail OAuth2 API que o nó Gmail usa, rodando no próprio aplicativo Google do n8n. O n8n deleta o campo de escopo em credenciais gerenciadas antes do fluxo começar, então o consentimento sempre solicita os escopos pré-registrados nesse app, os seis completos incluindo https://mail.google.com/, e nenhuma configuração de UI muda isso. O cliente OAuth é do n8n, então na verificação não há nenhum projeto seu para enviar.
Pode ser anexado aos nós HTTP Request, com Authentication definido como Predefined Credential Type e Credential Type Gmail OAuth2 API, mas ele carrega esses seis escopos consigo.
Um toggle Custom Scopes para a credencial Gmail foi integrado em 22 de julho e ainda não está em um release (2.32.3 não tem). Aplica-se apenas a credenciais OAuth2 personalizadas, já que as gerenciadas têm o escopo removido, então assim que for lançado você poderá rodar o próprio nó Gmail com apenas gmail.modify.

4

Para produção, escolha o caminho que oferece credenciais controladas, tratamento de refresh-token e um processo de revogação claro. Teste a expiração do token e o comportamento de reconexão em uma conta separada antes de decidir, pois a solicitação do caminho feliz se parece similar em ambas as configurações.