Managed OAuth vs. Generic OAuth für Gmail REST (HTTP Request) – Welcher Ansatz für die Produktion?

Fragen
1

Hallo zusammen,
ich baue einen produktiven E-Mail-Agent mit n8n Cloud und möchte gerne Feedback von Personen erhalten, die bereits Gmail-Integrationen in größerem Maßstab bereitgestellt haben.
Aktuelle Architektur
Ich verwende nicht den Gmail-Node.
Stattdessen nutze ich:
HTTP Request Nodes
Gmail REST API
Generische Google OAuth2-Authentifizierung
nur ein Scope:
https://www.googleapis.com/auth/gmail.modify
Der Workflow führt aus:
Ungelesene Nachrichten auflisten
Nachricht abrufen
Entwurf erstellen
Nachricht senden
Als gelesen markieren
Alles funktioniert korrekt.
Warum ich den Gmail-Node vermieden habe
Soweit ich verstehe, fordert der Gmail-Node mehrere feste Scopes an, darunter:

gmail.modify
gmail.compose
usw.
Ich wollte das Prinzip der geringsten Berechtigung befolgen und nur gmail.modify anfordern.
Deshalb bin ich zu HTTP Request + Generic OAuth2 gewechselt.
Meine Frage zu Managed OAuth
Ich evaluiere jetzt das auf n8n Cloud verfügbare Managed OAuth.
Die Dokumentation erklärt, dass es die Authentifizierung vereinfacht, aber ich konnte keine technischen Details über das finden, was tatsächlich dahinter passiert.
Ich würde gerne wissen:
Verwendet Managed OAuth intern die gleiche Gmail-Authentifizierung (gleiche Scopes) wie der Gmail-Node?
Kann ich eine Managed OAuth Gmail-Authentifizierung in HTTP Request Nodes verwenden, wenn ich sie erstellt habe?
Welche Scopes werden tatsächlich bei der Google-Zustimmung angefordert?
Gibt es eine Möglichkeit, Managed OAuth auf nur folgende zu beschränken:
gmail.modify
statt auf alle Gmail-Scopes?
Hat jemand einen produktiven Gmail REST Workflow erfolgreich mit Managed OAuth statt einer generischen OAuth-Authentifizierung bereitgestellt?
Google-Verifizierung
Ein weiterer Punkt, den ich verstehen möchte:
Ändert Managed OAuth etwas in Bezug auf Googles OAuth-Verifizierungsanforderungen (eingeschränkte Scopes, Sicherheitsbewertung usw.)?
Ich bitte nicht um rechtliche Beratung, sondern frage mich nur, ob jemand praktische Produktionserfahrung damit hat.
Jedes Feedback oder Produktionserfahrungen wären sehr willkommen.
Danke!

Problem/Fehler/Frage beschreiben

Welche Fehlermeldung wird angezeigt (falls vorhanden)?

Bitte teilen Sie Ihren Workflow

(Wählen Sie die Nodes auf Ihrer Canvas aus und verwenden Sie die Tastenkombinationen CMD+C/CTRL+C und CMD+V/CTRL+V, um den Workflow zu kopieren und einzufügen.)

Ausgabe des letzten Nodes teilen

Informationen zu Ihrem n8n-Setup

  • n8n-Version: cloud
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n ausgeführt über (Docker, npm, n8n cloud, Desktop-App): cloud
  • Betriebssystem:
2

Hallo @Jidenkaes

Dein vorhandenes Setup — Generic OAuth2 + HTTP Request + einzelner gmail.modify Scope — ist die richtige Wahl für einen produktiven Gmail-Agent, bei dem das Prinzip der minimalen Berechtigung wichtig ist. Managed OAuth ist nicht für die Anpassung von Scopes oder die Verwendung des HTTP Request-Knotens konzipiert, und ein Wechsel würde deine Scope-Oberfläche wahrscheinlich erweitern, nicht verringern. Bleib bei deiner aktuellen Architektur und veröffentliche deine GCP-App als Internal (falls innerhalb eines Google Workspace), um die öffentliche Verifizierungsanforderung ganz zu vermeiden.

Das sollte dir ein klareres Bild geben

image
image718×275 5.47 KB

3

Hi @Jidenkaes
Managed OAuth ist dieselbe Gmail OAuth2 API-Berechtigung, die der Gmail-Knoten verwendet und auf n8ns eigener Google-App läuft. n8n löscht das Scope-Feld bei verwalteten Anmeldedaten vor Beginn des Ablaufs, sodass die Zustimmung immer die auf dieser App vorregistrierten Bereiche anfordert – alle sechs einschließlich https://mail.google.com/ – und keine UI-Einstellung ändert das. Der OAuth-Client gehört n8n, daher gibt es bei der Verifizierung kein Projekt von dir zum Einreichen.
Es kann an HTTP Request-Knoten angehängt werden, Authentication auf Predefined Credential Type und Credential Type auf Gmail OAuth2 API gesetzt werden, aber es bringt diese sechs Bereiche mit sich.
Ein Custom Scopes-Schalter für die Gmail-Berechtigung wurde am 22. Juli zusammengeführt und ist noch nicht in einem Release enthalten (2.32.3 hat ihn nicht). Er gilt nur für benutzerdefinierte OAuth2-Anmeldedaten, da verwaltete Daten den Scope entfernt bekommen, sodass du, sobald es verfügbar ist, den Gmail-Knoten selbst nur mit gmail.modify ausführen kannst.

4

Für die Produktion wählen Sie den Pfad, der Ihnen kontrollierte Anmeldeinformationen, Refresh-Token-Handling und einen klaren Widerrufsprozess bietet. Testen Sie Token-Ablauf und Wiederverbindungsverhalten in einem separaten Konto, bevor Sie sich entscheiden, da die Happy-Path-Anfrage in beiden Setups ähnlich aussieht.