LinkedIn
Instagram
WhatsApp
Telegramm
Google Kalender
Slack-Gemeinschaft beitretenGmail API Dienstkonto & Delegation über Domänen hinwegDer Entwickler-Leitfaden 2026
Gmail API-Dienstkonto mit Domain-breiter Delegation einrichten: Vollständige Schritte in der Admin-Konsole, erforderliche Bereiche, harte Limits und ein ehrlicher Entscheidungsrahmen, wann DWD die falsche Wahl ist. Plus: die verwaltete OAuth-Alternative, die den Admin-Aufwand vollständig umgeht.
from google.oauth2 import Dienstkonto
from googleapiclient.discovery import bauen
# Anmeldedaten für das Dienstkonto laden
Referenzen = service_account.Credentials
.vom_servicekonto_datei(
'service-account-key.json',
Geltungsbereiche=['https://mail.google.com/']
)
# Als Benutzer eines Arbeitsbereichs auftreten (DWD)
delegiert = Guthaben.mit_Betreff(
'user@yourdomain.com'
)
#: Aufbau eines Gmail-Dienstes
Dienstleistung = bauen('Gmail', 'v1', Anmeldeinformationen=delegiert)Was ist ein Gmail API-Dienstkonto?
A Gmail API-Dienstkonto mit Domain-weiter Delegierung ist eine Google Cloud-Identität, die es einer Backend-Anwendung ermöglicht, auf Gmail-Daten beliebiger Nutzer in einer Google Workspace-Organisation zuzugreifen – ohne die Zustimmung einzelner Nutzer. Dem Dienstkonto wird in der Google Workspace Admin Console ein vertrauenswürdiges Administrator-Level gewährt, was es ihm ermöglicht, jeden Nutzer in der Domain mithilfe der OAuth 2.0 JWT-Authentifizierung zu impersonifizieren.
Im Gegensatz zu Standard-OAuth 2.0, bei dem jeder Benutzer Ihre App interaktiv autorisiert, Gmail API Dienstkonten Domain-weite delegieren lässt Ihren Servercode im Namen von Hunderten oder Tausenden von Workspace-Benutzern mit einer einzigen Service-Account-Anmeldeinformation Gmail-APIs aufrufen. Der Kompromiss: Es funktioniert nur für Google Workspace-Domains – nicht für persönliche @gmail.com-Konten.
Dieses Muster ist bei Unternehmens-Tools üblich: E-Mail-Archivierungssysteme, Compliance-Überwachungsplattformen, interne CRM-Integrationen und Kalender-/E-Mail-Synchronisierungsdienste, die domänenweit in einem Unternehmen funktionieren müssen, ohne dass jeder Mitarbeiter die Anwendung einzeln autorisieren muss.
Kein Einwilligungs-Workflow für Nutzer
Dienstkonten greifen im Namen von Workspace-Benutzern auf Gmail zu, ohne OAuth-Abfragen auszulösen.
Server-zu-Server-Authentifizierung
Verwendet JWTs, die mit einem privaten Schlüssel signiert sind - keine Browser-Umleitung, kein Austausch von Autorisierungscodes.
Domänenübergreifender Zugriff
Einmal von einem Workspace Super Admin autorisiert – gilt für alle Nutzer in der Organisation.
Dienstkonto vs. OAuth-Benutzerseite: Welches brauchen Sie wirklich?
Beide Muster verwenden OAuth 2.0 Scopes für den Zugriff auf Gmail, unterscheiden sich jedoch grundlegend in Bezug auf Architektur, Einrichtungsaufwand und Zielgruppe. Hier ist der ehrliche Vergleich – einschließlich der verwalteten Option, die beide Einrichtungspfade überspringt.
| Kriterien | Dienstkonto + DWD | OAuth Benutzerseite | Unipile verwaltet |
|---|---|---|---|
| Google Workspace erforderlich | Erforderlich | Nicht benötigt | Nicht benötigt |
| @gmail.com Support | Nein – nur Arbeitsbereich | Ja | Ja |
| Benutzerzustimmung erforderlich | Admin-Berechtigungen, nicht pro Benutzer | Jeder Benutzer stimmt zu | OAuth pro Benutzer, erledigt |
| Admin-Konsole einrichten | Erforderlich - komplexer Pfad | Nicht benötigt | Nicht benötigt |
| Geltungsbereichsprüfung durch Google | Erforderlich für eingeschränkte | Erforderlich für eingeschränkte | Unipile ist CASA Stufe 2 |
| CASA-Beurteilung | Deine Last | Deine Last | Erledigt |
| Multi-Tenant-SaaS-Freundlichkeit | Tenant-spezifische Verwaltung | Gut | Ausgezeichnet |
| Zeit bis zum ersten API-Aufruf | Tage (Admin-Genehmigung + Einrichtung) | Stunden | Protokoll |
Verwenden Sie Dienstkonten + DWD, wenn...
Verwenden Sie OAuth auf Benutzerseite, wenn...
Kritische Grenze: DWD funktioniert nicht mit @gmail.com-Konten
Dies ist der häufigste Fehler, den Teams bei der Auswahl machen Gmail API Dienstkonten Domain-weite delegieren. DWD kann nur Benutzer impersonieren, die zu einer Google Workspace-Domain gehören, die die Client-ID deines Dienstkontos ausdrücklich autorisiert hat. Persönliche @gmail.com-Adressen sind kein Teil einer Workspace-Domain und nicht nachgeahmt werden kann – der API-Aufruf gibt einen 400-Fehler mit admin_policy_enforced oder einen ungültigen Delegationsfehler. Wenn Ihr Produkt sowohl @gmail.com- als auch Workspace-Nutzer bedient, ist Dienstkonto + DWD nicht die richtige Wahl.
Gmail-Zugang ohne Workspace-Administrator benötigt? Unipiles verwaltetes OAuth funktioniert für @gmail.com- und Workspace-Benutzer mit einer einzigen einheitlichen API – keine DWD-Einrichtung erforderlich.
Verwenden Sie den Schlüssel von UnipileEinrichtung der domänenweiten Delegierung in Google Workspace (5 Schritte) 1. Erstellen Sie ein Dienstkonto 2. Erteilen Sie dem Dienstkonto die domänenweite Delegierung 3. Erstellen Sie einen API-Client-Zugriffsschlüssel 4. Aktivieren Sie die erforderlichen APIs 5. Benutzen Sie die Anmeldeinformationen in Ihrem Code
Hier ist das vollständige Verfahren von 2026 zur Konfiguration Gmail API Dienstkonten Domain-weite delegieren. Sie benötigen ein Google Cloud-Projekt, einen Workspace Super-Admin und etwa 30 Minuten für die erste Einrichtung.
Ein Dienstkonto in der Google Cloud Console erstellen
Geh Konsole.cloud.google.com, wählen Sie Ihr Projekt aus (oder erstellen Sie eines) und navigieren Sie dann zu IAM & Admin > Dienstkonten > Dienstkonto erstellen. Gib ihm einen beschreibenden Namen wie gmail-dwd-service. Sie müssen zu diesem Zeitpunkt keine Cloud IAM-Rollen zuweisen – die Berechtigungen stammen von der Google Workspace Admin Console und nicht von Cloud IAM.
Generieren und laden Sie den JSON-Schlüssel herunter
Auf der Detailseite des Dienstkontos, gehen Sie zu Schlüssel > Schlüssel hinzufügen > Neuen Schlüssel erstellen > JSON. Laden Sie die Datei herunter – dies sind die Anmeldedaten, die Ihre Anwendung zum Signieren von JWTs verwendet. Speichern Sie sie sicher: Behandeln Sie den JSON-Schlüssel wie ein privates SSL-Zertifikat. Kommittieren Sie ihn niemals in die Versionskontrolle.
Die JSON-Datei enthält die Kunden-E-Mail, Privater Schlüsselund client_id Felder, die Ihr Code benötigt. Alternativ zu dateibasierten Schlüsseln können Sie Workload Identity Federation für schlüssellose Authentifizierung in Produktionsumgebungen.
Gmail API aktivieren und erforderliche Bereiche identifizieren
Gehen Sie in der Google Cloud Console zu APIs & Dienste > APIs und Dienste aktivieren und aktivieren Sie die Gmail-API. Entscheiden Sie dann, welche OAuth-Bereiche (Scopes) Ihre Anwendung benötigt. Für die meisten Gmail-Vorgänge benötigen Sie mindestens https://www.googleapis.com/auth/gmail.readonly (sensibel) oder https://mail.google.com/ (eingeschränkt).
https://mail.google.com/) erfordern eine formelle Google-Sicherheitsüberprüfung und eine CASA-Bewertung der Stufe 2, bevor Sie sie in der Produktion verwenden können. Sehen Sie sich den vollständigen Geltungsbereich im nächsten Abschnitt und in der an Gmail OAuth-Bereiche: Eine tiefgehende Analyse für Einzelheiten zum Überprüfungsprozess.Client-ID in der Admin-Konsole autorisieren
Dies ist der Schritt, der Ihre Google Workspace Super-Administrator. Navigieren Sie in der Admin-Konsole zu:
Im Dialog "Neu hinzufügen" geben Sie das Dienstkonto ein numerische Client-ID (die eindeutige ID, die Sie in Schritt 1 notiert haben) und die Liste der durch Kommas getrennten OAuth-Berechtigungen. Zum Beispiel:
Speichern Sie den Eintrag. Die Änderungen werden in der Regel innerhalb weniger Minuten übernommen, können in großen Organisationen jedoch bis zu 60 Minuten dauern. Hinweis: Google Workspace Admin Hilfe – API-Zugriff mit domänenweiter Delegierung steuern.
Als ein Benutzer aus Ihrem Backend auftreten
Mit dem heruntergeladenen Dienstkontoschlüssel und der autorisierten DWD können Sie nun Gmail-APIs im Namen jedes Benutzers in der Domäne aufrufen. Der entscheidende Schritt ist der Aufruf mit_Subjekt() auf die Anmeldeinformationen, um den zu imitierenden Benutzer festzulegen.
from google.oauth2 import Dienstkonto
from googleapiclient.discovery import bauen
Geltungsbereiche = ['https://www.googleapis.com/auth/gmail.readonly']
SERVICE_KONTO_DATEI = 'service-account-key.json'
# Anmeldedaten aus JSON-Schlüssel laden
Berechtigungsnachweise = service_account.Credentials.vom_servicekonto_datei(
SERVICE_ACCOUNT_DATEI, Geltungsbereiche=Geltungsbereiche
)
# Als den Benutzer des Ziel-Arbeitsbereichs (DWD) auftreten
delegierte_Zugangsdaten = Anmeldeinformationen.mit_Betreff('user@yourdomain.com')
#: Aufbau des Gmail-Dienstes mit delegierten Anmeldedaten
Dienstleistung = bauen('Gmail', 'v1', Anmeldeinformationen=delegierte_anmeldeinformationen
# Die Labels im Posteingang des Benutzers auflisten
Ergebnisse = service.users().labels().list(userId=ich).ausführen()
printErgebnisseconst { Google } = require('googleapis');
const Auth = new google.auth.GoogleAuth({
Schlüsseldatei: 'service-account-key.json',
Geltungsbereiche: ['https://www.googleapis.com/auth/gmail.readonly'],
// Setze den Benutzer zum Annehmen (DWD)
clientOptionen: { betreff: 'user@yourdomain.com' }
});
const gmail = Google.gmail({ Version: 'v1', auth });
// Labels für den nachgeahmten Benutzer auflisten
const res = await gmail.users.labels.list({ userId: ich });
Konsole.log(res.data.labels);Erforderliche OAuth-Bereiche für Gmail DWD
Google stuft Gmail API-Bereiche in drei Stufen ein: Grundlegend, empfindlichund eingeschränkt. Die Stufe bestimmt, wie genau Google prüft, bevor Sie den Bereich in der Produktion verwenden können. Bei der domänenweiten delegierten Autorisierung müssen Sie alle Bereiche im Autorisierungseintrag der Admin-Konsole auflisten. Eine vollständige Aufschlüsselung aller Bereiche und wie der Verifizierungsprozess von Google aussieht, finden Sie unter Gmail OAuth Scopes im Detail.
| Umfang | Zugriffsebene | Ebene | Google-Bewertung erforderlich |
|---|---|---|---|
| https://www.googleapis.com/auth/gmail.readonly | Alle Nachrichten und Metadaten lesen | Empfindlich | Ja - OAuth-Einwilligungsbildschirm-Überprüfung |
| https://www.googleapis.com/auth/gmail.send | E-Mail im Namen des Benutzers senden | Empfindlich | Ja - OAuth-Einwilligungsbildschirm-Überprüfung |
| https://www.googleapis.com/auth/gmail.modify | Lesen, verfassen, senden, löschen (nicht dauerhaft) | Empfindlich | Ja - OAuth-Einwilligungsbildschirm-Überprüfung |
| https://www.googleapis.com/auth/gmail.labels | Labels erstellen, lesen, aktualisieren, löschen | Grundlegend | Nein |
| https://www.googleapis.com/auth/gmail.metadata | Nachrichtenmetadaten lesen (Header, kein Body) | Grundlegend | Nein |
| https://mail.google.com/ | Voller Zugriff - lesen, schreiben, senden, löschen alles | Eingeschränkt | Ja - vollständige Sicherheitsbewertung + CASA Tier 2 |
| https://www.googleapis.com/auth/gmail.settings.basic | Grundeinstellungen für E-Mails verwalten (Filter, Labels) | Empfindlich | Ja - OAuth-Einwilligungsbildschirm-Überprüfung |
| https://www.googleapis.com/auth/gmail.settings.sharing | Sensible Einstellungen verwalten (Weiterleitung, IMAP/POP) | Eingeschränkt | Ja - vollständige Sicherheitsbewertung + CASA Tier 2 |
Gmail-spezifische Grenzwerte und Fallstricke
Bevor Sie sich verpflichten Gmail API Dienstkonten Domain-weite delegieren, diese Einschränkungen kennen. Einige sind harte technische Limits von Google, andere sind Richtlinienanforderungen, die verhindern können, dass Ihre App live geschaltet wird. Zur Fehlerbehebung wie admin_policy_enforced, siehe die Gmail API-Fehlerleitfaden.
125 Delegierte maximal pro Benutzer
Gmail setzt ein hartes Limit von 25 Mail-Delegierte pro Benutzerkonto. Dies ist eine nutzerspezifische Kontingentbeschränkung, die auf Gmail-Ebene und nicht auf der Google Cloud API-Kontingentebene erzwungen wird. Wenn Sie ein Compliance- oder Archivierungstool erstellen, das unternehmensweit eingesetzt werden soll, planen Sie Ihre Architektur frühzeitig um diese Beschränkung herum. Sie können keine Erhöhung bei Google beantragen.
2Primäre E-Mail erforderlich, keine Alias-Adresse
Beim Anrufen mit_Subjekt() oder das JWT setzen unter Anspruch, Sie müssen die des Benutzers verwenden Primäre E-Mail-Adresse, nicht eine Alias-Adresse oder eine E-Mail-Gruppe. Zum Beispiel, wenn die primäre Adresse eines Benutzers lautet john@company.com aber sie haben auch john.smith@company.com Als Alias müssen Sie die primäre verwenden. Die Verwendung eines Alias führt zu einem Authentifizierungsfehler von der Gmail API.
Ebenso können E-Mail-Gruppenadressen (wie team@company.com) können nicht mit DWD imitiert werden – Gruppen sind keine einzelnen Benutzerkonten.
3CASA Tier 2 Jahresbeurteilung für eingeschränkte Geltungsbereiche
Wenn Ihre Anwendung etwas verwendet eingeschränkte Gmail-Bereiche wie zum Beispiel https://mail.google.com/), Google verlangt von Ihnen, dass Sie eine übergeben CASA (Cloud Application Security Assessment) Stufe 2 Bewertung, bevor Ihre Anwendung auf Gmail-Daten für externe Nutzer zugreifen kann. Dies ist eine jährliche Anforderung, keine einmalige Zertifizierung.
CASA Tier 2 wird von einem von Google zugelassenen Sicherheitsbewerter durchgeführt. Die Bewertung umfasst die Sicherheitsarchitektur Ihrer App, die Praktiken der Datenverarbeitung und die Zugriffskontrollen. Zeitplan: Budget 4-8 Wochen und tatsächliche Kosten. Dies ist eine erhebliche Hürde für Teams in der Anfangsphase.
4Mehrparteien-Genehmigungen (Google August 2024 Update)
Ab August 2024 hat Google eingeführt Mehrparteienfreigabe für bestimmte administrative Aktionen mit hohen Berechtigungen in Google Workspace. Abhängig von Ihrer Workspace Edition (Business Standard, Enterprise usw.) und den Sicherheitseinstellungen Ihrer Organisation kann die Autorisierung einer neuen Client-ID für domänenweite Delegierung jetzt die Bestätigung der Aktion durch einen zweiten Super-Admin erfordern, bevor sie wirksam wird.
Das bedeutet, dass der Weg "einen Administrator zur Genehmigung von DWD bewegen" nicht mehr garantiert in einem Schritt für alle Organisationen funktioniert. Überprüfen Sie die Workspace-Admin-Richtlinien Ihrer Organisation und die Google Workspace Updates Blog für die neuesten Anforderungen, bevor der Einrichtungsprozess mit dem IT-Team eines Kunden beginnt.
Wann ein Dienstkonto NICHT verwendet werden sollte + DWD (das Problem der SaaS-Multi-Tenancy)
Dieser Abschnitt ist derjenige, den die meisten Reiseführer überspringen. Domainweite Delegierung von Gmail API-Dienstkonten ist ein mächtiges, aber eingeschränktes Werkzeug. Wenn eines dieser Szenarien Ihre Situation beschreibt, wird DWD entweder gar nicht funktionieren oder einen operativen Mehraufwand verursachen, der den Nutzen überwiegt. Die Wahl von DWD in diesen Fällen ist ein häufiger und kostspieliger Fehler.
B2C- oder PLG-Produkt für @gmail.com-Nutzer
Wenn Ihr Produkt einen Self-Service-Anmeldevorgang hat und Ihre Nutzer auch persönliche @gmail.com Konten, DWD ist architektonisch inkompatibel mit Ihrem Anwendungsfall. DWD kann keine @gmail.com-Konten nachahmen – Punkt. Sie benötigen eine standardmäßige OAuth-Benutzerautorisierung für jeden Benutzer, der sich registriert, unabhängig davon, ob er zufällig auch ein Workspace-Konto besitzt.
Multi-Tenant-SaaS mit Kunden in unterschiedlichen Workspace-Domänen
Wenn jeder Ihrer Kunden ein anderes Unternehmen mit eigener Google Workspace-Domain ist, benötigen Sie eine DWD-Autorisierung von einem Super-Admin bei jeder einzelnen Kundenorganisation trennen. Das ist nicht skalierbar. Jeder IT-Administrator des Kunden muss den 5-stufigen Einrichtungsprozess unabhängig durchführen. Standardmäßige OAuth-Benutzerautorisierung – oder eine verwaltete OAuth-Lösung – eignet sich weitaus besser für Mandantenprodukte, bei denen Ihre Benutzer viele verschiedene Organisationen umfassen.
Kein Zugriff auf einen Google Workspace Super-Admin
DWD erfordert ein Google Workspace Super-Admin, um die Client-ID Ihres Dienstkontos zu autorisieren in der Admin-Konsole. Wenn Ihre Zielbenutzer oder Ihre eigene Organisation keinen Super-Admin zur Verfügung haben oder wenn der IT-Genehmigungsprozess Wochen bis Monate dauert, wird DWD Ihren gesamten Markteinführungsplan blockieren. Dies ist in regulierten Branchen, großen Unternehmen und Organisationen mit strengen Change-Management-Prozessen üblich.
Kurze Markteinführungszeit, noch kein CASA-Budget
Wenn Sie sich vor dem Product-Market-Fit befinden und eine Gmail-Integration benötigen in Tagen statt Wochen laufen, die kombinierte Zeitlinie für: (1) die Erstellung eines Google Cloud-Projekts, (2) das Warten auf die Verbreitung der Admin-Konsole, (3) die OAuth-App-Überprüfung durch Google für sensible Bereiche und (4) die Planung von CASA Tier 2 für eingeschränkte Bereiche - ist prohibitiv. Allein der Admin-Tanz kann länger dauern als Ihr Sprint. Ein verwalteter OAuth-Anbieter, der diese Überprüfungen bereits bestanden hat, ist eine legitime technische Wahl und nicht nur eine Abkürzung.
Umgehe den administrativen Aufwand
Unipile bietet gehostetes OAuth für Gmail, Outlook und IMAP. CASA Tier 2 zertifiziert. Kein DWD-Setup, keine Admin-Konsole. Funktioniert sowohl für @gmail.com- als auch für Workspace-Nutzer.
Die verwaltete Alternative: gehostetes OAuth mit Unipile
Wenn Ihre Situation Sie dazu bringt Gmail API Dienstkonten Domain-weite delegieren die falsche Entscheidung – oder wenn Sie einfach die 5-stufige Einrichtung, die CASA-Bewertung und die jährliche Verlängerung vermeiden möchten – gibt es eine legitime technische Alternative. Unipile fungiert als unabhängiger technischer Vermittler, der den OAuth-Flow im Namen jedes authentifizierten Benutzers verwaltet. Dies ist keine Umgehungslösung für die Sicherheitsüberprüfung von Google. Unipile hat die CASA Tier 2-Zertifizierung abgeschlossen und operiert im Rahmen des von Google genehmigten Konzepts.
CASA Tier 2 zertifiziert
Unipile hat Googles Cloud Application Security Assessment auf Stufe 2 bestanden. Ihre verknüpften Konten greifen über eine bereits verifizierte Plattform auf Gmail zu – keine Prüfung auf Ihrer Seite.
Im Namen jedes Benutzers
Jeder API-Aufruf, den Unipile an Gmail macht, erfolgt im Namen jedes authentifizierten Benutzers einzeln unter Verwendung seines eigenen OAuth-Tokens. Keine gemeinsamen Anmeldedaten, keine domänenweite Nachahmung erforderlich.
Einzelne einheitliche API
Eine API für Gmail, Outlook und IMAP. Wechseln Sie Anbieter oder fügen Sie neue verknüpfte Konten hinzu, ohne Ihren Integrationscode zu ändern.
Google Mail
Ausblick
IMAP
import Anfragen
# Unipile verwaltet den OAuth-Ablauf für jedes verknüpfte Konto
# – Kein Dienstkonto, kein DWD, keine Einrichtung der Admin-Konsole erforderlich
Kopfzeilen = {
"X-API-KEY": "DEIN_UNIPILE_API_SCHLÜSSEL",
"akzeptieren": "application/json"
}
# E-Mails aus einem verknüpften Gmail- oder Outlook-Konto auflisten
response = Anfragen.bekommen.(
"https://api.unipile.com/api/v1/emails",
Kopfzeilen=Kopfzeilen,
Parameter={"Konto_ID": "acc_user_gmail_123"}
)
print(response.json())Gmail API Dienstkonten & DWD FAQ
Häufig gestellte Fragen zur Domain-weiten Delegation von Gmail API-Dienstkonten, zu Geltungsbereichen, Limits und wann man eine verwaltete Alternative wählen sollte.
A Gmail-Dienstkonto ist eine spezielle Google Cloud-Identität (kein menschlicher Benutzer), die sich bei der Gmail API mittels eines privaten JSON-Schlüssels anstatt interaktiver OAuth authentifiziert. In Kombination mit domänenweite delegierung, ermöglicht es einer serverseitigen Anwendung, im Namen eines beliebigen Benutzers in einer Google Workspace-Organisation auf Gmail zuzugreifen, ohne dass dieser Benutzer die App manuell autorisieren muss. Sie ist für den automatisierten Server-zu-Server-Zugriff in Unternehmensumgebungen konzipiert.
A Gmail API Dienstkonto + DWD verwendet Server-zu-Server-JWT-Authentifizierung und kann stillschweigend jeden Workspace-Benutzer impersonieren, ohne dass pro Benutzer eine Zustimmung erforderlich ist. Standard-OAuth-Benutzerseite erfordert, dass jeder Benutzer einen interaktiven Zustimmungsbildschirm durchläuft, funktioniert aber für jeden Gmail-Benutzer, einschließlich privater @gmail.com-Konten. Dienstkonten eignen sich für unternehmensinterne Tools; OAuth auf Benutzerseite eignet sich für SaaS-Produkte mit unterschiedlichen Benutzerbasen. Eine vollständige Vergleichsübersicht, einschließlich der verwalteten Option, finden Sie unter Vergleichstabelle oben.
Mehr erfahren über Unipile Gmail API Produktseite.Nein. Dies ist die kritischste Einschränkung beim Domain-wide Delegation (DWD) für Gmail API Service-Konten. Persönliche Adressen mit @gmail.com sind nicht Teil einer verwalteten Workspace-Domain, daher gibt es keinen Administrator, der die DWD-Delegation genehmigen kann. Der Versuch, einen Benutzer mit @gmail.com-Konto zu imitieren, führt zu einem Authentifizierungsfehler. Wenn Ihr Produkt Benutzer mit @gmail.com-Konten bedient, müssen Sie die standardmäßige OAuth-Benutzerautorisierung oder einen verwalteten Anbieter wie Unipile verwenden, der OAuth sowohl für @gmail.com- als auch für Workspace-Benutzer handhabt.
Navigieren Sie in der Google Workspace Admin Console (erfordert Super Admin) zu: Menü > Sicherheit > Zugriffs- und Datenkontrolle > API-Steuerelemente > Delegierung über die gesamte Domain > Delegierung über die gesamte Domain verwalten > Neu hinzufügen. Geben Sie die numerische Client-ID Ihres Dienstkontos und die durch Kommas getrennte Liste der OAuth-Bereiche ein. Speichern Sie und warten Sie bis zu 60 Minuten auf die Verbreitung. Die vollständige Schritt-für-Schritt-Anleitung finden Sie im Einrichtungsanleitung in diesem Artikel. Referenz: Google Admin Hilfe - Domänenweite Delegation.
Domänenweite Delegation ist nicht veraltet ab 2026, aber es ist eingeschränkter. Google hat im August 2024 die Mehrparteienfreigabe für bestimmte Aktionen mit hohen Administratorrechten eingeführt, was zur Genehmigung von DWD-Berechtigungen einen zweiten Superadministrator erfordern kann. Darüber hinaus die Verwendung eingeschränkter Gmail-Bereiche, wie z. B https://mail.google.com/ jetzt benötigt eine CASA Stufe 2 jährliche Sicherheitsbewertung. DWD bleibt ein valides Muster für echte interne Tool-Anwendungsfälle in Unternehmen, jedoch ist der Compliance-Overhead gestiegen.
Erforderliche Berechtigungen hängen davon ab, was Ihre App tut. Nur lesen https://www.googleapis.com/auth/gmail.readonly (sensibel, benötigt Google-Verifizierung). E-Mail senden: https://www.googleapis.com/auth/gmail.send (sensibel). Vollständiger Postfachzugriff: https://mail.google.com/ (eingeschränkt, erfordert CASA Tier 2 Bewertung). Nur Metadaten: https://www.googleapis.com/auth/gmail.metadata (Basis, keine Überprüfung). Du musst alle erforderlichen Bereiche in der Admin Console DWD-Eintragung angeben. Siehe Gesamtumfangsliste in diesem Leitfaden.
Noch Fragen zur domainweiten Delegation des Gmail API-Dienstkontos? Unser Team kann Ihnen helfen, die richtige Architektur für Ihren Anwendungsfall auszuwählen.
Sprechen Sie mit einem Experten
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR