OAuth géré vs OAuth générique pour Gmail REST (HTTP Request) – Quelle approche pour la production ?

Questions
1

Bonjour à tous,
Je construis un agent e-mail de production avec n8n Cloud et j’aimerais recueillir des retours de personnes qui ont déjà déployé des intégrations Gmail à grande échelle.
Architecture actuelle
Je n’utilise pas le nœud Gmail.
À la place, j’utilise :
nœuds HTTP Request
Gmail REST API
Identifiant Google OAuth2 générique
uniquement une portée :
https://www.googleapis.com/auth/gmail.modify
Le flux de travail effectue :
lister les messages non lus
obtenir le message
créer un brouillon
envoyer le message
marquer comme lu
Tout fonctionne correctement.
Pourquoi j’ai évité le nœud Gmail
D’après ce que je comprends, le nœud Gmail demande plusieurs portées fixes incluant :

gmail.modify
gmail.compose
etc.
Je voulais suivre le principe du moindre privilège et demander uniquement gmail.modify.
C’est pourquoi j’ai basculé vers HTTP Request + OAuth2 générique.
Ma question sur Managed OAuth
J’évalue maintenant Managed OAuth disponible sur n8n Cloud.
La documentation explique qu’elle simplifie l’authentification, mais je n’ai pas trouvé de détails techniques sur ce qui se passe réellement en arrière-plan.
J’aimerais savoir :
Managed OAuth utilise-t-elle en interne les mêmes identifiants Gmail (mêmes portées) que le nœud Gmail ?
Si je crée un identifiant Gmail Managed OAuth, puis-je l’utiliser dans les nœuds HTTP Request ?
Durant le consentement Google, quelles portées sont réellement demandées ?
Y a-t-il un moyen de limiter Managed OAuth à uniquement :
gmail.modify
au lieu des portées Gmail complètes ?
Quelqu’un a-t-il déployé avec succès un flux de travail Gmail REST de production utilisant Managed OAuth au lieu d’un identifiant OAuth générique ?
Vérification Google
Une autre chose que j’essaie de comprendre :
Managed OAuth change-t-elle quelque chose concernant les exigences de vérification OAuth de Google (portées restreintes, évaluation de sécurité, etc.) ?
Je ne demande pas de conseil juridique, je me demande juste si quelqu’un a une expérience de production réelle avec cela.
Toute réaction ou expérience de production serait très appréciée.
Merci !

Décrivez le problème/l’erreur/la question

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre flux de travail

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie renvoyée par le dernier nœud

Informations sur votre configuration n8n

  • version n8n : cloud
  • Base de données (par défaut : SQLite) :
  • paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution d’n8n via (Docker, npm, n8n cloud, application de bureau) : cloud
  • Système d’exploitation :
2

Salut @Jidenkaes

Votre configuration existante — OAuth2 générique + HTTP Request + portée unique gmail.modify — est le bon choix pour un agent Gmail en production où le principe du moindre privilège compte. OAuth géré n’est pas conçu pour la personnalisation des portées ou l’utilisation du nœud HTTP Request, et le passage à celui-ci risquerait d’élargir votre surface de portée, plutôt que de la réduire. Conservez votre architecture actuelle et publiez votre application GCP comme Interne (si elle se trouve dans un Google Workspace) pour éviter entièrement l’exigence de vérification publique.

Ceci devrait vous donner une vue plus claire

image
image718×275 5.47 KB

3

Salut @Jidenkaes
L’OAuth géré est la même credential Gmail OAuth2 API que le nœud Gmail utilise, fonctionnant sur l’application Google propre à n8n. n8n supprime le champ d’étendue des credentials gérées avant le démarrage du flux, donc le consentement demande toujours les étendues pré-enregistrées sur cette application, les six complets incluant https://mail.google.com/, et aucun paramètre d’interface utilisateur ne change cela. Le client OAuth est celui de n8n, donc à la vérification, il n’y a pas de projet vôtre à soumettre.
Il peut être attaché aux nœuds HTTP Request, avec Authentication défini sur Predefined Credential Type et Credential Type Gmail OAuth2 API, mais il porte ces six étendues avec lui.
Un bouton bascule Custom Scopes pour la credential Gmail a été fusionné le 22 juillet et ne figure pas encore dans une version (2.32.3 ne l’a pas). Il s’applique uniquement aux credentials OAuth2 personnalisées, car les credentials gérées ont l’étendue supprimée, donc une fois qu’elle sera disponible, vous pourrez exécuter le nœud Gmail lui-même sur gmail.modify uniquement.

4

Pour la production, choisissez le chemin qui vous donne des identifiants contrôlés, une gestion des jetons de rafraîchissement et un processus de révocation clair. Testez l’expiration des jetons et le comportement de reconnexion dans un compte séparé avant de décider, car la requête du chemin heureux se ressemble dans les deux configurations.