LinkedIn
Instagram
WhatsApp
Telegram
Kalendarz Google
Dołącz do społeczności SlackUsługa konta Gmail API Delegacja w całej domenie: Przewodnik dla deweloperów 2026
Konfiguracja konta usługi Gmail API z delegacją na poziomie domeny: pełne kroki w Konsoli administratora, wymagane zakresy, twarde limity i uczciwe ramy decyzyjne dotyczące tego, kiedy delegacja na poziomie domeny jest złym wyborem. Plus: alternatywa OAuth zarządzana przez aplikację, która całkowicie omija taniec administracyjny.
z google.oauth2 import konto usługi
z googleapiclient.discovery import budować
# Wczytaj dane logowania do konta serwisowego
poświadczenia = service\_account.Credentials
.z_pliku_konta_usługi(
'pl: 'klucz-konta-usługi.json',
zakresy=['https://mail.google.com/']
)
# Podszywanie się pod użytkownika obszaru roboczego (DWD)
delegowane = dane uwierzytelniające.z_tematem(
'user@yourdomain.com'
)
# – usługa poczty Gmail
usługa = budować('gmail', 'v1', poświadczenia=delegowane)Czym jest konto usługi Gmail API?
A Konto usługi Gmail API z delegacją obejmującą całą domenę to tożsamość Google Cloud, która umożliwia aplikacji backendowej dostęp do danych Gmail każdego użytkownika w organizacji Google Workspace – bez indywidualnej zgody użytkownika. Konto usługi otrzymuje zaufanie na poziomie administratora w konsoli administracyjnej Google Workspace, co pozwala mu na podszywanie się pod dowolnego użytkownika w domenie przy użyciu uwierzytelniania OAuth 2.0 JWT.
W przeciwieństwie do standardowego protokołu OAuth 2.0, gdzie każdy użytkownik autoryzuje aplikację interaktywnie, delegacja domenowa konta usługi Gmail API pozwól kodowi serwera wywoływać API Gmail w imieniu setek lub tysięcy użytkowników Workspace za pomocą jednego poświadczenia konta usługi. Kompromis: działa tylko w domenach Google Workspace – nie działa w przypadku prywatnych kont @gmail.com.
Ten wzorzec jest powszechny w narzędziach korporacyjnych: systemach archiwizacji poczty e-mail, platformach monitorowania zgodności, wewnętrznych integracjach CRM oraz usługach synchronizacji kalendarzy/poczty e-mail, które muszą działać w całej domenie firmy, bez konieczności indywidualnego autoryzowania aplikacji przez każdego pracownika.
Brak procedury uzyskiwania zgody użytkownika
Konto usługi uzyskuje dostęp do Gmail w imieniu użytkowników Workspace bez wywoływania monitów OAuth.
Uwierzytelnianie serwer-serwer
Używa JWT podpisanych kluczem prywatnym - brak przekierowania przeglądarki, brak wymiany kodu autoryzacyjnego.
Dostęp w zakresie domeny
Po zatwierdzeniu przez administratora nadrzędnego obszaru roboczego – ma zastosowanie do wszystkich użytkowników w organizacji.
Konto usługi vs użytkownik OAuth: czego właściwie potrzebujesz?
Oba wzorce wykorzystują zakresy OAuth 2.0 do uzyskiwania dostępu do Gmaila, ale zasadniczo różnią się architekturą, kosztami konfiguracji i tym, dla kogo są przeznaczone. Oto szczere porównanie – w tym opcja zarządzana, która całkowicie pomija obie ścieżki konfiguracji.
| Kryteria | Konto Usługi + DWD | Użytkownik OAuth | Unipile zarządzał |
|---|---|---|---|
| Wymagane jest Google Workspace | Wymagany | Niepotrzebne | Niepotrzebne |
| pomoc@gmail.com | Nie - tylko przestrzeń robocza | Tak | Tak |
| Potrzebna zgoda użytkownika | Administracyjne nadania, bez nadawania per użytkownik | Każdy użytkownik wyraża zgodę | OAuth dla użytkownika, obsłużone |
| Ustawienia konsoli administracyjnej | Wymagany - złożona ścieżka | Niepotrzebne | Niepotrzebne |
| Weryfikacja zakresu przez Google | Wymagane dla ograniczonego | Wymagane dla ograniczonego | Unipile jest CASA Tier 2 |
| Ocena CASA | Twój ciężar | Twój ciężar | Już zrobione |
| Przyjazność dla SaaS wielodostępnego | Administrator per-tenanta | Dobrze | Świetnie |
| Czas do pierwszego wywołania API | Dni (zatwierdzenie przez administratora + konfiguracja) | Godziny | Protokół |
Użyj konta usługi + DWD, gdy...
Użyj OAuth po stronie użytkownika, gdy...
Krytyczny limit: DWD nie działa na kontach @gmail.com
To najczęstszy błąd, jaki popełniają zespoły przy wyborze delegacja domenowa konta usługi Gmail API. DWD może podszywać się pod użytkowników należących do domeny Google Workspace, która wyraźnie autoryzowała identyfikator klienta Twojego konta usługi. Osobiste adresy @gmail.com nie należą do żadnej domeny Workspace i nie można podszyć się pod niego - wywołanie API zwróci błąd 400 z admin_policy_enforced lub błąd nieprawidłowego delegowania. Jeśli Twój produkt obsługuje zarówno użytkowników @gmail.com, jak i Workspace, konto usługi + DWD nie jest właściwym wyborem.
Potrzebujesz dostępu do Gmail bez administratora Workspace? Zarządzany OAuth Unipile działa dla użytkowników @gmail.com i Workspace za pomocą jednego, zunifikowanego API – nie jest wymagana konfiguracja DWD.
Użyj klucza UnipileJak skonfigurować delegację w całej organizacji w Google Workspace (5 kroków)
Oto kompletna procedura 2026 dotycząca konfiguracji delegacja domenowa konta usługi Gmail API. Potrzebujesz projektu Google Cloud, administratora Workspace z uprawnieniami Super Admin oraz około 30 minut na początkową konfigurację.
Utwórz konto usługi w Google Cloud Console
Idź do console.cloud.google.com, wybierz swój projekt (lub utwórz nowy), a następnie przejdź do IAM i Administrator > Konta usług > Utwórz konto usługi. Nadaj mu opisową nazwę, taką jak usługa-gmail-dwd. Na tym etapie nie musisz przypisywać żadnych ról Cloud IAM – uprawnienia pochodzą z Konsoli administratora Google Workspace, a nie z Cloud IAM.
Wygeneruj i pobierz klucz JSON
Na stronie szczegółów konta usługi przejdź do Klucze > Dodaj klucz > Utwórz nowy klucz > JSON. Pobierz plik – to poświadczenie, którego Twoja aplikacja będzie używać do podpisywania tokenów JWT. Przechowuj go bezpiecznie: traktuj klucz JSON jak prywatny certyfikat SSL. Nigdy nie umieszczaj go w systemie kontroli wersji.
Plik JSON zawiera e_mail_klienta, klucz_prywatnyoraz client_id pól, których potrzebuje Twój kod. Alternatywnie do kluczy opartych na plikach, możesz użyć Federacja tożsamości obciążenia do bezkluczowego uwierzytelniania w środowiskach produkcyjnych.
Włącz interfejs API Gmail i zidentyfikuj wymagane zakresy
W Google Cloud Console przejdź do Interfejsy API i usługi > Włącz interfejsy API i usługi i włącz Gmail API. Następnie zdecyduj, jakich zakresów OAuth potrzebuje Twoja aplikacja. Do większości operacji Gmail potrzebujesz co najmniej https://www.googleapis.com/auth/gmail.readonly (wrażliwe) lub https://mail.google.com/ (ograniczony).
https://mail.google.com/) wymagają formalnej oceny bezpieczeństwa Google oraz oceny Tier 2 CASA przed użyciem ich w produkcji. Pełne odniesienie do zakresu znajdziesz w następnej sekcji oraz w Szczegółowe omówienie zakresów OAuth Gmail po szczegóły dotyczące procesu recenzji.Autoryzuj identyfikator klienta w Konsoli administratora
To jest krok, który wymaga Twojego Google Workspace Super Administrator. Przejdź w Konsoli administratora do:
W oknie dialogowym "Dodaj nowe" wpisz nazwę konta usługi numer identyfikacyjny klienta (unikalny identyfikator, który zanotowałeś w kroku 1) oraz lista zakresów OAuth oddzielonych przecinkami. Na przykład:
Zapisz wpis. Zmiany zazwyczaj propagują się w ciągu kilku minut, ale w dużych organizacjach mogą potrwać do 60 minut. Odnośnik: Pomoc administratora Google Workspace — Kontroluj dostęp do interfejsu API za pomocą delegacji w całej domenie.
Podaję się za użytkownika z mojego zaplecza.
Po pobraniu klucza konta usługi i autoryzacji DWD można teraz wywoływać interfejsy API Gmaila w imieniu dowolnego użytkownika w domenie. Kluczowym krokiem jest wywołanie z_tematem() na poświadczenia, aby ustawić użytkownika do podszywania się.
z google.oauth2 import konto usługi
z googleapiclient.discovery import budować
ZAKRESY = ['https://www.googleapis.com/auth/gmail.readonly']
PLIK_KONTA_USŁUGI = 'pl: 'klucz-konta-usługi.json'
# Wczytaj podstawowe dane uwierzytelniające z klucza JSON
referencje = service_account.Credentials.z_pliku_konta_usługi(
PLIK_KONTA_USŁUG, zakresy=ZAKRESY
)
# Podszywanie się pod użytkownika docelowego obszaru roboczego (DWD)
poświadczenia delegowane = poświadczenia.z_tematem('user@yourdomain.com')
# Stworzenie usługi Gmail przy użyciu poświadczeń delegowanych
usługa = budować('gmail', 'v1', poświadczenia=delegated_creds)
# Wyświetl etykiety skrzynki odbiorczej użytkownika
wyniki = service.users().labels().list(identyfikatorUżytkownika='ja').wykonaj()
print(wyniki)const { google } = require('googleapis');
const autoryzacja = nowy google.auth.GoogleAuth({
plikKlucza: 'pl: 'klucz-konta-usługi.json',
zakresy: ['https://www.googleapis.com/auth/gmail.readonly'],
// Ustaw użytkownika do podszywania się (DWD)
opcjeKlienta: { temat: 'user@yourdomain.com' }
});
const gmail = google.gmail({ wersja: 'v1', auth });
// Lista etykiet dla podszywającego się użytkownika
const res = czekać gmail.users.labels.list({ userId: 'ja' });
konsola.log(rez.dane.etykiety);Wymagane zakresy OAuth dla Gmail DWD
Google dzieli zasięgi interfejsu API Gmail na trzy poziomy: podstawowy, wrażliwyoraz ograniczony. Poziom ten określa, jak rygorystyczne jest sprawdzanie przez Google przed możliwością wykorzystania zakresu w środowisku produkcyjnym. W przypadku delegacji obejmującej całą domenę, wszystkie zakresy należy umieścić w poświadczeniu autoryzacji konsoli administratora. Aby uzyskać pełne zestawienie wszystkich zakresów i szczegółowe informacje na temat procesu weryfikacji przez Google, zobacz Szczegółowe omówienie zakresów Gmail OAuth.
| Zakres | Poziom dostępu | Poziom | Recenzja Google wymagana |
|---|---|---|---|
| https://www.googleapis.com/auth/gmail.readonly | Przeczytaj wszystkie wiadomości i metadane | Wrażliwy | Tak - weryfikacja ekranu zgody OAuth |
| https://www.googleapis.com/auth/gmail.send | Wyślij wiadomość e-mail w imieniu użytkownika | Wrażliwy | Tak - weryfikacja ekranu zgody OAuth |
| https://www.googleapis.com/auth/gmail.modify | Czytaj, pisz, wysyłaj, usuwaj (nie trwale) | Wrażliwy | Tak - weryfikacja ekranu zgody OAuth |
| https://www.googleapis.com/auth/gmail.labels | Tworzenie, odczyt, aktualizacja, usuwanie etykiet | Podstawowy | Nie |
| https://www.googleapis.com/auth/gmail.metadata | Odczytaj metadane wiadomości (nagłówki, bez treści) | Podstawowy | Nie |
| https://mail.google.com/ | Pełny dostęp - odczyt, zapis, wysyłanie, usuwanie wszystkiego | Ograniczony | Tak - pełna ocena bezpieczeństwa + CASA Tier 2 |
| https://www.googleapis.com/auth/gmail.settings.basic | Zarządzaj podstawowymi ustawieniami poczty (filtry, etykiety) | Wrażliwy | Tak - weryfikacja ekranu zgody OAuth |
| https://www.googleapis.com/auth/gmail.settings.sharing | Zarządzaj wrażliwymi ustawieniami (przekazywanie, IMAP/POP) | Ograniczony | Tak - pełna ocena bezpieczeństwa + CASA Tier 2 |
Limity i uwagi specyficzne dla Gmaila
Zanim podejmiesz decyzję o delegacja domenowa konta usługi Gmail API, poznaj te ograniczenia. Niektóre z nich to sztywne limity techniczne Google; inne to wymagania zasad, które mogą zablokować wdrożenie Twojej aplikacji. W przypadku rozwiązywania problemów, takich jak admin_policy_enforced, zobacz Przewodnik po błędach Gmail API.
1maksymalnie 25 delegatów na użytkownika
Gmail narzuca ścisły limit 25 delegatów poczty e-mail na konto użytkownika. Jest to limit na użytkownika egzekwowany na poziomie Gmail, a nie na poziomie limitów API Google Cloud. Jeśli tworzysz narzędzie do zgodności lub archiwizacji, które ma działać w dużej organizacji, uwzględnij ten limit w swojej architekturze na wczesnym etapie. Nie możesz ubiegać się o zwiększenie limitu od Google.
2Podstawowy adres e-mail wymagany, bez aliasu
Podczas dzwonienia z_tematem() lub ustawianie JWT sub postulat, musisz użyć użytkownika główny adres e-mail, nie alias ani grupa e-mailowa. Na przykład, jeśli główny adres użytkownika to john@company.com ale oni również mają john.smith@company.com Przy aliasie musisz użyć tego głównego. Użycie aliasu spowoduje błąd uwierzytelniania z interfejsu API Gmaila.
Podobnie, grupowe adresy e-mail (jak team@company.com) nie można podszyć się za pomocą DWD – grupy nie są indywidualnymi kontami użytkowników.
3Roczna ocena CASA Tier 2 dla ograniczonych zakresów
Jeśli twoja aplikacja wykorzystuje jakiekolwiek ograniczone zakresy Gmail (takie jak https://mail.google.com/), Google wymaga od Ciebie przejścia CASA (Ocena Bezpieczeństwa Aplikacji Chmurowych) Poziom 2 ocena przed uzyskaniem przez Twoją aplikację dostępu do danych Gmail użytkowników zewnętrznych. Jest to wymóg roczny, a nie jednorazowa certyfikacja.
Ocena CASA Tier 2 jest przeprowadzana przez zatwierdzonego przez Google asesora ds. bezpieczeństwa. Ocena obejmuje architekturę bezpieczeństwa aplikacji, praktyki dotyczące przetwarzania danych i mechanizmy kontroli dostępu. Harmonogram: szacunkowo 4-8 tygodni, rzeczywisty koszt. Jest to znacząca przeszkoda dla zespołów na wczesnym etapie rozwoju.
4Zatwierdzenia wielostronne (aktualizacja Google z sierpnia 2024 r.)
Od sierpnia 2024 r. Google wprowadził akceptacja wielostronna dla pewnych akcji administracyjnych o wysokim poziomie uprawnień w Google Workspace. W zależności od wersji Workspace (Business Standard, Enterprise itp.) i ustawień bezpieczeństwa organizacji, autoryzacja nowego identyfikatora klienta w celu delegowania uprawnień w całym obszarze domen może od teraz wymagać potwierdzenia tej akcji przez drugiego Super Administratora, zanim wejdzie ona w życie.
Oznacza to, że ścieżka "uzyskaj zgodę jednego administratora na DWD" nie gwarantuje już jednokrokowego rozwiązania dla wszystkich organizacji. Sprawdź zasady administratora Workspace w swojej organizacji oraz Blog Google Workspace Updates w celu uzyskania najnowszych wymagań przed rozpoczęciem procesu konfiguracji z zespołem IT klienta.
Kiedy NIE używać konta usługi + DWD (problem wielodzierżawowy w SaaS)
Ten rozdział jest tym, który większość przewodników pomija. Delegacja Gmail API na poziomie domeny dla kont usługi jest potężnym, ale ograniczonym narzędziem. Jeśli którykolwiek z tych scenariuszy opisuje Państwa sytuację, DWD nie będzie działać wcale lub stworzy obciążenie operacyjne przewyższające korzyści. Wybór DWD w tych przypadkach jest powszechnym i kosztownym błędem.
Produkt B2C lub PLG obsługujący użytkowników @gmail.com
Jeśli Twój produkt ma samoobsługowy proces rejestracji, a Twoi użytkownicy to osoby z osobistymi konta @gmail.com, DWD jest architektonicznie niekompatybilny z twoim przypadkiem użycia. DWD nie może podszywać się pod konta @gmail.com – kropka. Potrzebujesz standardowego uwierzytelniania OAuth po stronie użytkownika dla każdego użytkownika, który się rejestruje, niezależnie od tego, czy przypadkowo posiada również konto Workspace.
Wielodostępne rozwiązanie SaaS z klientami w różnych domenach Workspace
Jeśli każdy z Twoich klientów jest inną firmą z własną domeną Google Workspace, będziesz potrzebować oddziel autoryzację DWD od Super Admins we wszystkich organizacjach klientów. Nie jest to skalowalne. Administrator IT każdego klienta musi samodzielnie przejść 5-etapowy proces konfiguracji. Standardowa autoryzacja użytkownika OAuth – lub zarządzane rozwiązanie OAuth – jest znacznie lepiej dopasowana do produktów wielodostępnych, w których użytkownicy pochodzą z wielu różnych organizacji.
Brak dostępu do Głównego administratora Google Workspace
DWD wymaga Super administrator usługi Google Workspace autoryzuje identyfikator klienta konta usługi w Konsoli administratora. Jeśli Twoi użytkownicy docelowi lub Twoja własna organizacja nie mają dostępnego Super administratora, lub jeśli proces zatwierdzania przez dział IT trwa tygodnie lub miesiące, DWD zablokuje cały Twój proces wprowadzania produktów na rynek. Jest to powszechne w branżach regulowanych, dużych przedsiębiorstwach i organizacjach o rygorystycznych procesach zarządzania zmianą.
Szybkie wprowadzenie na rynek, jeszcze bez budżetu na CASA
Jeśli jesteś przed dopasowaniem produktu do rynku i potrzebujesz integracji z Gmail bieganie w dniach zamiast tygodni, połączony harmonogram: (1) utworzenia projektu Google Cloud, (2) oczekiwania na propagację konsoli administracyjnej, (3) przejścia przez weryfikację aplikacji Google OAuth pod kątem wrażliwych zakresów i (4) planowania CASA Tier 2 dla ograniczonych zakresów – jest zaporowy. Sam "taniec administratorów" może zająć więcej czasu niż sprint. Zarządzany dostawca OAuth, który przeszedł już te weryfikacje, jest rozsądnym wyborem inżynieryjnym, a nie tylko skrótem.
Omiń te administracyjne formalności
Unipile zapewnia hosting OAuth dla Gmail, Outlook i IMAP. Certyfikat CASA Tier 2. Bez konfiguracji DWD, bez Konsoli Administratora. Działa zarówno dla użytkowników @gmail.com, jak i Workspace.
Zarządzana alternatywa: hostowany OAuth z Unipile
Jeśli twoja sytuacja sprawia delegacja domenowa konta usługi Gmail API złą decyzję – lub jeśli po prostu chcesz uniknąć 5-etapowej konfiguracji, oceny CASA i rocznego odnowienia – istnieje legalna alternatywa inżynierska. Unipile działa jako niezależny pośrednik techniczny, zarządzając przepływem OAuth w imieniu każdego uwierzytelnionego użytkownika. Nie jest to obejście procesu przeglądu bezpieczeństwa Google. Unipile ukończył certyfikację CASA Tier 2 i działa w ramach zatwierdzonych przez Google.
Certyfikat CASA Tier 2
Unipile pomyślnie przeszedł ocenę bezpieczeństwa aplikacji Google Cloud na poziomie 2. Twoje połączone konta uzyskują dostęp do Gmaila za pośrednictwem już zweryfikowanej platformy – ocena po Twojej stronie nie jest wymagana.
W imieniu każdego użytkownika
Każde wywołanie API, które Unipile wykonuje do Gmaila, odbywa się w imieniu każdego uwierzytelnionego użytkownika indywidualnie, z wykorzystaniem jego własnego tokenu OAuth. Brak współdzielonych danych uwierzytelniających, brak wymogu podszywania się pod domenę.
Jedno ujednolicone API
Jedno API dla Gmail, Outlook i IMAP. Zmieniaj dostawców lub dodawaj nowe połączone konta bez zmiany kodu integracji.
Gmail
Perspektywy
IMAP
import żądania
# Unipile obsługuje proces OAuth dla każdego połączonego konta
# Nie wymaga konta serwisowego, nie wymaga DWD, nie wymaga konfiguracji konsoli administracyjnej
nagłówki = {
"X-API-KEY": "TWÓJ_KLUCZ_API_UNIPILE",
"akceptuj": "application/json"
}
# Wyświetl listę adresów e-mail z połączonego konta Gmail lub Outlook
response = żądania.uzyskać(
"https://api.unipile.com/api/v1/emails",
nagłówki=nagłówki,
parametry={"account_id": "acc_user_gmail_123"}
)
print(response.json())Gmail API Konto Usługi i FAQ DWD
Najczęściej zadawane pytania dotyczące delegowania uprawnień na poziomie domeny w przypadku kont usługowych Gmail API, zakresów, limitów i kiedy wybrać zarządzaną alternatywę.
A Konto usługi Gmail jest specjalną tożsamością Google Cloud (nie użytkownikiem ludzkim), która uwierzytelnia się w interfejsie Gmail API przy użyciu prywatnego klucza JSON, zamiast interaktywnego OAuth. W połączeniu z delegacja w domenie, umożliwia aplikacji po stronie serwera dostęp do poczty Gmail w imieniu dowolnego użytkownika w organizacji Google Workspace, bez konieczności ręcznego autoryzowania aplikacji przez tego użytkownika. Jest przeznaczony do zautomatyzowanego dostępu serwer-serwer w środowiskach korporacyjnych.
A Konto usługi Gmail API + DWD wykorzystuje uwierzytelnianie JWT typu server-to-server i może cicho podszywać się pod dowolnego użytkownika Workspace, bez przepływu zgody dla każdego użytkownika. Standard OAuth po stronie użytkownika wymaga od każdego użytkownika przejścia przez interaktywny ekran zgody, ale działa dla każdego użytkownika Gmail, w tym osobistych kont @gmail.com. Konta usługi nadają się do wewnętrznych narzędzi dla przedsiębiorstw; OAuth po stronie użytkownika nadaje się do produktów SaaS z zróżnicowaną bazą użytkowników. Pełne porównanie, w tym opcja zarządzana, można znaleźć w tabela porównawcza powyżej.
Dowiedz się więcej na temat Strona produktu Unipile Gmail API.Nie. Jest to najbardziej krytyczne ograniczenie delegowania na poziomie domeny w Google Workspace dla kont służbowych (Workspace) w interfejsie API Gmaila. Prywatne adresy @gmail.com nie są częścią zarządzanej domeny Workspace, więc nie ma administratora do autoryzacji delegowania na poziomie domeny. Próba podszycia się pod użytkownika @gmail.com spowoduje błąd uwierzytelnienia. Jeśli Twój produkt obsługuje użytkowników z kontami @gmail.com, musisz użyć standardowego uwierzytelniania OAuth po stronie użytkownika lub zarządzanego dostawcy, takiego jak Unipile, który obsługuje OAuth zarówno dla użytkowników @gmail.com, jak i Workspace.
W Google Workspace Admin Console (wymaga uprawnień Super Administratora) przejdź do: Menu > Zabezpieczenia > Kontrola dostępu i danych > Kontrolki API > Delegacja w całej domenie > Zarządzaj delegacją w całej domenie > Dodaj nowy. Wprowadź numeryczny identyfikator klienta swojego konta usługi i listę zakresów OAuth oddzielonych przecinkami. Zapisz i poczekaj do 60 minut na propagację. Pełne instrukcje krok po kroku znajdziesz w Instrukcja konfiguracji w tym artykule. Odnośnik: Pomoc administratora Google - Delegacja na poziomie domeny.
Delegacja domenowa to nieprzestarzały na rok 2026, ale jest bardziej ograniczony. Google wprowadził wielostronne zatwierdzanie dla pewnych działań administratora o wysokich uprawnieniach w sierpniu 2024 r., co może wymagać zatwierdzenia autoryzacji DWD przez drugiego Super Administratora. Dodatkowo, użycie ograniczonych zakresów Gmail, takich jak https://mail.google.com/ teraz wymaga CASA Poziom 2 coroczne oceny bezpieczeństwa. DWD pozostaje ważnym wzorcem dla prawdziwych zastosowań wewnętrznych narzędzi przedsiębiorstwa, ale narzut związany z zgodnością wzrósł.
Wymagane zakresy zależą od tego, co robi Twoja aplikacja. Tylko do odczytu: https://www.googleapis.com/auth/gmail.readonly (wrażliwe, wymaga weryfikacji Google). Wyślij e-mail: https://www.googleapis.com/auth/gmail.send (wrażliwe). Pełny dostęp do skrzynki pocztowej: https://mail.google.com/ (wymaga oceny CASA Tier 2). Tylko metadane: https://www.googleapis.com/auth/gmail.metadata (podstawowe, bez przeglądu). Należy uwzględnić wszystkie wymagane zakresy w wpisie konsoli administracyjnej DWD. Patrz pełny zakres tabeli w tym przewodniku.
Nadal masz pytania dotyczące delegacji dostępu w całej domenie dla usługi konta usługi Gmail API? Nasz zespół pomoże Ci wybrać odpowiednią architekturę dla Twojego przypadku użycia.
Porozmawiaj z ekspertem
PL 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
TR