Verificação OAuth do Google com nó Gmail: como passar na verificação quando GmailOAuth2Api força 6 escopos?

Perguntas
1

Oi pessoal,

Estou desenvolvendo um assistente de email com IA auto-hospedado usando n8n para pequenas empresas e estou me preparando para a verificação do Google OAuth.

O fluxo de trabalho:

  • Lê mensagens não lidas do Gmail
  • Filtra emails automatizados
  • Envia o conteúdo para Claude
  • Cria rascunhos no Gmail
  • Marca a mensagem como lida apenas após o processamento bem-sucedido
  • Envia um resumo da execução

O aplicativo nunca deleta emails permanentemente.

O que descobri

Após investigar, descobri que a credencial nativa Gmail OAuth2 API tem seus escopos codificados.

Sempre solicita:

  • gmail.labels
  • gmail.addons.current.action.compose
  • gmail.addons.current.message.action
  • mail.google.com
  • gmail.modify
  • gmail.compose

A propriedade Scope fica oculta, portanto não há como personalizá-la pela interface.

Também encontrei discussões na comunidade mostrando que simplesmente restringir escopos no Google Cloud causa falha na autorização OAuth com HTTP 403 porque a credencial do Gmail ainda solicita a lista de escopos codificados completa.

Também há uma solicitação de recurso aberta pedindo que o nó do Gmail suporte a credencial genérica do Google OAuth em vez da credencial fixa do Gmail.

Minha pergunta

Alguém aqui já completou a verificação OAuth do Google mantendo o nó nativo do Gmail?

Se sim:

  • O Google aceitou os escopos padrão codificados?
  • Você teve que justificar mail.google.com?
  • O Google solicitou alguma mudança?

Ou você acabou substituindo os nós do Gmail por nós HTTP Request usando uma credencial genérica do Google OAuth2 e a API REST do Gmail?

Não estou procurando por conselhos teóricos — realmente gostaria de feedback de alguém que completou com sucesso o processo de verificação do Google com um aplicativo n8n em produção.

Obrigado!

Compartilhe seu fluxo de trabalho

(Selecione os nós na 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 n8n

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

Oi @Jidenkaes
O bloqueador não são os seis escopos como grupo, é que o nó nativo do Gmail hardcoda https://mail.google.com/, um escopo restrito (acesso total, incluindo exclusão permanente). Esse único escopo é o que te coloca na trilha de escopo restrito do Google: a avaliação de segurança de terceiros anualmente, além de revisores rejeitarem uma solicitação de acesso total de um app que apenas lê, cria rascunhos e marca como lido.

Seu fluxo inteiro (ler não lidos, criar rascunhos, remover o rótulo UNREAD) se encaixa em um escopo, gmail.modify. O Google o classifica como sensível em vez de restrito, especificamente porque não consegue excluir mail permanentemente, o que o seu nunca faz. Isso mantém você na verificação de escopo sensível mais leve em vez da restrita, e te dá uma justificativa clara de privilégio mínimo.

O nó do Gmail não te permite reduzir seus escopos, então substitua esses nós por nós HTTP Request que acessam a API REST do Gmail, autenticados com uma credencial genérica de API Google OAuth2 onde você insere o escopo você mesmo:

https://www.googleapis.com/auth/gmail.modify
3

Obrigado, isso é muito útil. Só para esclarecer: você pessoalmente completou a verificação OAuth do Google usando a abordagem HTTP Request + genérica OAuth2 do Google, ou essa é a arquitetura que você recomendaria? Estou tentando determinar se alguém passou com sucesso na revisão do Google com essa configuração.