OAuth administrado vs OAuth genérico para Gmail REST (HTTP Request) – ¿Cuál es el mejor enfoque para producción?

Preguntas
1

Hola a todos,
Estoy construyendo un agente de correo electrónico de producción con n8n Cloud y me gustaría obtener comentarios de personas que ya han desplegado integraciones de Gmail a escala.
Arquitectura actual
No estoy usando el nodo de Gmail.
En su lugar, estoy usando:
Nodos HTTP Request
Gmail REST API
Credencial genérica de Google OAuth2
solamente un alcance:
https://www.googleapis.com/auth/gmail.modify
El flujo de trabajo realiza:
listar mensajes no leídos
obtener mensaje
crear borrador
enviar mensaje
marcar como leído
Todo funciona correctamente.
Por qué evité el nodo de Gmail
De lo que entiendo, el nodo de Gmail solicita varios alcances fijos incluyendo:

gmail.modify
gmail.compose
etc.
Quería seguir el principio del menor privilegio y solicitar solo gmail.modify.
Por eso cambié a HTTP Request + OAuth2 genérico.
Mi pregunta sobre OAuth administrado
Ahora estoy evaluando OAuth administrado disponible en n8n Cloud.
La documentación explica que simplifica la autenticación, pero no pude encontrar detalles técnicos sobre qué sucede realmente detrás de escenas.
Me gustaría saber:
¿Utiliza OAuth administrado internamente la misma credencial de Gmail (los mismos alcances) que el nodo de Gmail?
¿Si creo una credencial de Gmail con OAuth administrado, puedo usarla dentro de nodos HTTP Request?
Durante el consentimiento de Google, ¿qué alcances se solicitan realmente?
¿Hay alguna manera de limitar OAuth administrado a solo:
gmail.modify
en lugar de los alcances completos de Gmail?
¿Ha desplegado alguien exitosamente un flujo de trabajo de Gmail REST de producción usando OAuth administrado en lugar de una credencial OAuth genérica?
Verificación de Google
Otra cosa que intento entender:
¿Cambia OAuth administrado algo con respecto a los requisitos de verificación de OAuth de Google (alcances restringidos, evaluación de seguridad, etc.)?
No estoy pidiendo asesoramiento legal, solo me pregunto si alguien tiene experiencia de producción real con esto.
Qualquier comentario o experiencia de producción sería muy apreciado.
¡Gracias!

Describe el problema/error/pregunta

¿Cuál es el mensaje de error (si los hay)?

Comparta su flujo de trabajo

(Seleccione los nodos en su lienzo y use los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparta el resultado devuelto por el último nodo

Información sobre su configuración de n8n

  • versión de n8n: cloud
  • Base de datos (predeterminada: SQLite):
  • Configuración de n8n EXECUTIONS_PROCESS (predeterminada: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio): cloud
  • Sistema operativo:
2

Hola @Jidenkaes

Tu configuración existente — OAuth2 genérico + HTTP Request + scope único gmail.modify — es la opción correcta para un agente de Gmail en producción donde el principio de menor privilegio es importante. OAuth administrado no está diseñado para personalización de scopes o uso del nodo HTTP Request, y cambiar a él probablemente expandiría tu superficie de scope, no la reduciría. Mantén tu arquitectura actual y publica tu aplicación GCP como Interna (si está dentro de un Google Workspace) para evitar completamente el requisito de verificación pública.

Esto debería darte una imagen más clara

image
image718×275 5.47 KB

3

Hola @Jidenkaes
Managed OAuth es la misma credencial de Gmail OAuth2 API que usa el nodo de Gmail, ejecutándose en la propia aplicación de Google de n8n. n8n elimina el campo de alcance en las credenciales administradas antes de que comience el flujo, por lo que el consentimiento siempre solicita los alcances preregistrados en esa aplicación, los seis completos incluyendo https://mail.google.com/, y ninguna configuración de interfaz de usuario cambia eso. El cliente OAuth es de n8n, por lo que en la verificación no hay ningún proyecto tuyo que enviar.
Puede adjuntarse a nodos de HTTP Request, con Autenticación establecida en Predefined Credential Type y Tipo de credencial Gmail OAuth2 API, pero lleva esos seis alcances con él.
Un botón de alternancia de Custom Scopes para la credencial de Gmail se fusionó el 22 de julio y aún no está en una versión (2.32.3 no la tiene). Se aplica solo a credenciales OAuth2 personalizadas, ya que las administradas obtienen el alcance eliminado, por lo que una vez que se lance podrás ejecutar el nodo de Gmail mismo solo en gmail.modify.

4

Para producción, elige la ruta que te proporcione credenciales controladas, manejo de tokens de actualización y un proceso de revocación claro. Prueba la expiración de tokens y el comportamiento de reconexión en una cuenta separada antes de decidir, porque la solicitud de caso feliz se ve similar en ambas configuraciones.