LinkedIn
Instagram
WhatsApp
Telegram
Kalendarz Google
Dołącz do społeczności SlackKlucz API Gmail vs OAuthDlaczego nie możesz pominąć OAuth
Czy można użyć klucza API Google do dostępu do Gmaila? Krótka odpowiedź: nie. Gmail API uzyskuje dostęp do prywatnych danych użytkownika, co oznacza, że każde żądanie wymaga wyraźnej zgody użytkownika za pośrednictwem protokołu OAuth 2.0. Ten przewodnik omawia dokładny błąd, który zobaczysz, próbując użyć klucza API, 3 dostępne obecnie ścieżki uwierzytelniania i jak połączyć skrzynkę pocztową Gmaila w 3 liniach kodu za pomocą ujednolicone API pocztowe.
Klucz API Gmail a OAuth – werdykt
// ----------------------------------------
// ŹLE: Klucz API NIE działa z Gmail
const res = czekać fetch(
`https://gmail.googleapis.com/gmail/v1/
users/me/messages?key=TWOJE_KLUCZE_API`
);
Zwraca: 401 Wymagane logowanie
// POPRAWNIE: Token dostępu OAuth 2.0
const res = czekać fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Bearer ${accessToken}`
} }
);
// LUB pominąć OAuth całkowicie - użyć Unipile
const maile = czekać unipile.e-mail.list(
{ idKonta: 'identyfikator-połączonego-konta' }
);
Czy można użyć klucza API z Gmail API?
Jeśli wcześniej korzystałeś z Google Cloud, wiesz, że klucze API działają bez zarzutu dla Map lub Tłumacza. Naturalne jest więc wypróbowanie tego samego podejścia z Gmail. To się nie uda. Oto, co dokładnie się dzieje i dlaczego – a także werdykt w dwóch zdaniach, zanim zagłębimy się w szczegóły.
Nie. Klucze API Google nie mogą uwierzytelniać się w API Gmaila. Gmail uzyskuje dostęp do prywatnych danych użytkownika, co wymaga wyraźnej zgody użytkownika za pośrednictwem OAuth 2.0. Nie ma żadnej flagi, nagłówka ani obejścia, które pozwalałoby zastąpić klucz API tokenem dostępu OAuth w jakimkolwiek punkcie końcowym Gmaila. Gmail API zwróci 401 Wymagane logowanie lub Przekroczono 403 dzienny limit dla użytku nieautoryzowanego błąd za każdym razem.
Klucz API - Działa tylko dla danych publicznych
Klucz API identyfikuje Twój projekt Google Cloud na potrzeby rozliczeń i limitów. Działa z publicznymi interfejsami API (Mapy, Tłumacz, publiczne dane YouTube), które nie obsługują kont użytkowników. Gmail nigdy nie jest publicznym danymi.
OAuth 2.0 - Wymagane dla Gmail API
OAuth 2.0 generuje token dostępu specyficzny dla użytkownika po tym, jak użytkownik wyraźnie udzieli zgody. Gmail API odczytuje ten token przy każdym żądaniu, aby zweryfikować zarówno tożsamość użytkownika, jak i zatwierdzony zakres dostępu. Brak ważnego tokenu dostępu oznacza brak odpowiedzi.
Co tak naprawdę robi klucz API w Google Cloud (i czego nie robi)
Klucze API i tokeny OAuth to dwa odrębne mechanizmy, które rozwiązują dwa różne problemy. Mylenie ich jest jednym z najczęstszych błędów przy rozpoczynaniu pracy z interfejsami API Google. Oto ich przejrzyste rozgraniczenie.
Platforma Google Maps - Geokodowanie, Wskazówki dojazdu, Miejsca (nie wymaga konta użytkownika)
API Tłumaczenia w Chmurze - Tłumaczenie tekstu, wykrywanie języków
API danych YouTube - Odczyt metadanych publicznych filmów, kanałów, list odtwarzania
Chmura Wizja / Język naturalny - API uczenia maszynowego przetwarzające przesyłane przez Ciebie treści
Rozliczanie + śledzenie limitów - Całe użycie klucza API jest mierzone w odniesieniu do Twojego projektu
Gmail API - Odczytywanie, wysyłanie lub zarządzanie skrzynką pocztową dowolnego użytkownika
Interfejs API kalendarza Google - Odczytywanie lub zapisywanie zdarzeń w kalendarzu użytkownika
API Dysku Google - Dostęp do plików użytkownika, przesyłanie ich lub umieszczanie na liście
Google Workspace Admin SDK - Dowolna operacja na domenie z uprawnieniami administratora
Ludzie API (dane użytkowników) - Każdy punkt końcowy, który ma dostęp do kontaktów lub profilu użytkownika
Zasada jest prosta: Jeśli API uzyskuje dostęp do danych konta użytkownika, Google wymaga uwierzytelnienia tego użytkownika za pomocą protokołu OAuth 2.0. Klucze API to dane uwierzytelniające projektu, a nie użytkownika. Gmail API zawsze dotyczy danych użytkownika. Bez wyjątków. Ta zasada obowiązuje niezależnie od tego, czy Twoja aplikacja jest publiczna, czy wewnętrzna dla Twojej firmy.
Dlaczego Gmail wymaga OAuth 2.0
OAuth 2.0 nie jest biurokratyczną przeszkodą wymyśloną przez Google, aby Cię spowolnić. Jest to jedyny technicznie poprawny sposób na udzielenie dostępu do prywatnych danych użytkownika z określonym zakresem, możliwością cofnięcia i możliwością audytu. Trzy podstawowe wymagania Gmaila wyjaśniają, dlaczego klucz API nigdy nie może go zastąpić.
Zgoda użytkownika nie podlega negocjacjom
Dane Gmail należą do użytkownika, a nie do twojej aplikacji. OAuth 2.0 to mechanizm, dzięki któremu użytkownik wyraźnie mówi "tak, ta aplikacja może odczytywać moją skrzynkę odbiorczą". Brak zgody = brak dostępu. Jest to wymóg prawny na mocy RODO i polityka platformy Google, a nie tylko ograniczenie techniczne.
Dostęp ograniczony, odwoływalny
Tokeny OAuth posiadają zakresy – precyzyjne deklaracje tego, co aplikacja może, a czego nie może robić (tylko do odczytu, wysyłanie, pełny dostęp). Użytkownicy mogą dokładnie zobaczyć, jakie uprawnienia przyznali i w każdej chwili odebrać je w ustawieniach swojego Konta Google. Klucz API niczego nie przyznaje i nie może niczego odebrać na poziomie użytkownika.
Wygaśnięcie tokena chroni użytkowników
Tokeny dostępu do interfejsu API Gmaila wygasają (zazwyczaj po 1 godzinie). Oznacza to, że skradziony token jest bezużyteczny po krótkim czasie. Twoja aplikacja musi cicho odświeżać tokeny za pomocą tokena odświeżającego – który sam może zostać unieważniony. Klucze API natomiast są długożywotnymi poświadczeniami projektu bez mechanizmu unieważniania na poziomie użytkownika.
Google wycofał uwierzytelnianie użytkownika/hasła ("Basic Auth") dla Gmaila w Wrzesień 2024. Jeśli posiadasz jakiekolwiek starsze integracje wykorzystujące bezpośrednio zapisane dane uwierzytelniające, przestały one działać. Protokół OAuth 2.0 jest jedynym pozostałym mechanizmem uwierzytelniania dla interfejsu API Gmaila – zarówno dla nowych, jak i zmigrowanych integracji. Zobacz oficjalne ogłoszenie Google.
Potrzebujesz obsługi OAuth dla wielu kont Gmail w swoim SaaS? Unipile zarządza ekranem zgody, wymianą tokenów i cichym odświeżaniem dla każdego połączonego konta – dzięki czemu Twój kod nigdy nie dotyka tokenu.
Zbuduj to z Unipile3 ścieżki uwierzytelniania dla Gmail API
Gdy zaakceptujesz, że OAuth jest nieunikniony, pojawia się pytanie: która ścieżka OAuth pasuje do Twojego przypadku użycia? Istnieją trzy architektonicznie odrębne opcje – każda z innymi kompromisami w zakresie złożoności, zakresu użytkowników i obciążenia konserwacyjnego.
| Kryterium | Identyfikator klienta OAuth 2.0 (3-stopniowy) | Konto Usługi + DWD | Zjednoczone API (Unipile) |
|---|---|---|---|
| Wymagana zgoda użytkownika? | |||
| Działa z osobistym Gmailem? | |||
| SaaS wielodostępny? | |||
| Zarządzanie tokenami | Twój kod przechowuje tokeny odświeżania. Wymagający / Kosztowny w utrzymaniu |
Klucz JSON konta usługi Zarządzane przez administratora |
Unipile obsługuje wszystkie tokeny Zero konserwacji |
| Przegląd ekranu zgody Google? | |||
| Również obsługuje Outlook + IMAP? | |||
| Czas do pierwszego przeczytania e-maila | 2-4 godziny konfiguracji Aplikacja OAuth + zakresy + ekran zgody |
1-2 godziny konfiguracji Wymagany administrator obszaru roboczego |
Poniżej 15 minut Klucz API + połączone konto |
| Najlepszy dla | Aplikacje SaaS łączące Gmail użytkowników zewnętrznych | Wewnętrzne narzędzia do pracy dla Twojej organizacji | Dowolny przypadek użycia API poczty e-mail – bez operacji OAuth |
Ścieżka 1 - Identyfikator klienta OAuth 2.0 (wielodostępny SaaS)
Jeśli tworzysz produkt SaaS, do którego Twoi klienci podłączają własne konta Gmail, standardową ścieżką jest przepływ autoryzacji kodem OAuth 2.0. Jest to przepływ trójstopniowy: Twoja aplikacja, Google i użytkownik końcowy. Wymaga to skonfigurowania projektu w Google Cloud i przejścia przez proces weryfikacji ekranu zgody dla wrażliwych zakresów. Aby zagłębić się w Przepływ OAuth dla interfejsów API poczty e-mail szczegółowo, zobacz nasz dedykowany przewodnik.
Utwórz dane uwierzytelniające OAuth 2.0 w Google Cloud Console
Przejdź do sekcji API i usługi > Dane logowania > Utwórz dane logowania > Identyfikator klienta OAuth. Wybierz opcję "Aplikacja internetowa". Skonfiguruj autoryzowane URI przekierowań dla swojej aplikacji. Spowoduje to wygenerowanie Twojego client_id oraz client_secret.
Włącz interfejs API Gmail i zadeklaruj swoje zakresy
Przejdź do sekcji API i usługi > Ekran zgody OAuth. Dodaj potrzebne zakresy Gmail (np. gmail.tylko_do_odczytu, gmail.wyślij. Obszary wrażliwe i ograniczone wymagają weryfikacji przez Google – proces ten trwa od kilku dni do kilku tygodni.
Przekieruj użytkowników do adresu URL autoryzacji Google
Gdy użytkownik kliknie "Połącz Gmail" w Twojej aplikacji, przekieruj go do Google z Twoim client_id, zakresy, i przekierowanie_uri. Po zatwierdzeniu przez nich Google odsyła kod autoryzacyjny do Twojego URI przekierowania.
Wymień kod na tokeny i przechowaj token odświeżania
Wyślij kod autoryzacyjny do punktu końcowego tokenów Google. Otrzymujesz token_dostępu (ważne ~1h) i a token_odświeżający (długo żyjący). Bezpiecznie przechowuj token odświeżania — dzięki niemu możesz uzyskać nowe tokeny dostępu bez ponownego proszenia użytkownika.
const { google } = require('googleapis');
const oauth2Klient = nowy google.auth.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_REDIRECT_URI
);
// Krok 1: Zbuduj adres URL autoryzacji
const authUrl = oauth2Klient.generujAdresURLAutoryzacji({
typ_dostępu: 'nieaktywny', // pobierz token odświeżający
zakres: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Krok 2: Wymiana kodu na tokeny (w programie obsługi wywołania zwrotnego)
async function obsługa zwrotna{
const { tokenów } = czekać oauth2Klient.pobierzToken(kod);
oauth2Klient.ustawPoświadczenia(tokeny);
// Bezpiecznie przechowuj tokeny.refresh_token w swojej bazie danych
return tokeny;
}
// Krok 3: Użyj tokena dostępu do wywołania Gmail API
async function listMessages(token dostępu) {
const gmail = google.gmail({ wersja: 'v1', auth: klientOauth2 });
const res = czekać gmail.users.messages.list({ userId: 'ja' });
return res.data.wiadomości;
}Zarządzanie tokenami odświeżającymi na dużą skalę stanowi główny problem w #1 samodzielnie zarządzanym Gmailu, OAuth. Rotacja tokenów, migracje baz danych, ciche błędy związane z wygasłymi tokenami – wszystko to jest obsługiwane automatycznie, gdy używasz ujednolicony dostawca interfejsu API poczty e-mail.
Zintegruj swój GmailŚcieżka 2 – Konto usługi + Delegowanie w całej domenie (Wewnętrzne Workspace)
Jeśli przypadek użycia dotyczy wewnętrznych potrzeb organizacji Google Workspace — takich jak narzędzia wewnętrzne, automatyzacja procesów HR czy firmowy pulpit analityki poczty e-mail — konta usługi z delegacją w domenie (DWD) umożliwiają dostęp do skrzynek pocztowych bez konieczności uzyskiwania zgody użytkownika. Administrator Workspace udziela tej delegacji jednorazowo. Istotne zastrzeżenie: ta metoda nie działa w przypadku prywatnych adresów Gmail.
Konta usługi nie mogą uzyskiwać dostępu do osobistych kont Gmail (@gmail.com). DWD działa tylko w domenie Google Workspace. Jeśli Twoi użytkownicy rejestrują się za pomocą prywatnych adresów Gmail, musisz użyć ścieżki 1 (Client ID OAuth) lub ścieżki 3 (Unified API). Próba użycia DWD na prywatnym koncie zwraca błąd 403.
Wymagany administrator obszaru roboczego: DWD musi zostać skonfigurowane przez administratora Google Workspace pod adresem admin.google.com. Nie możesz tego zrobić jako deweloper bez dostępu administratora.
Bezpieczeństwo kluczy JSON: Klucz JSON konta usługi jest poświadczeniem długoterminowym. Traktuj go jak klucz prywatny – regularnie go zmieniaj i nigdy nie umieszczaj w kontroli wersji.
Wymagane zadeklarowanie zakresu działania: Administrator musi jawnie zatwierdzić każdy zakres Gmail podczas konfiguracji DWD. Nie można żądać zakresów w czasie wykonywania. Zobacz Przewodnik Google DWD.
z google.oauth2 import konto usługi
z googleapiclient.discovery import budować
# Ścieżka do klucza JSON Twojego konta serwisowego
PLIK_KONTA_USŁUGI = 'service-account.json'
ZAKRESY = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# Podszywanie się pod użytkownika w domenie Workspace
# (uprawnienia dla całej domeny muszą zostać przyznane przez administratora)
def usługa_gmail(adres_email_użytkownika):
poświadczenia = service_account.Credentials.z_pliku_konta_usługi(
PLIK_KONTA_USŁUGI,
zakresy=ZAKRESY
)
# To jest delegowanie uprawnień w całej domenie: podszywanie się pod użytkownika
poświadczenia delegowane = dane uwierzytelniające.z_tematem(adres_email_użytkownika)
return budować('gmail', 'v1', poświadczenia=delegated_creds)
# Wyświetl listę wiadomości dla użytkownika obszaru roboczego
usługa = usługa_gmail('alice@yourcompany.com')
wyniki = usługi.użytkownicy().wiadomości().list(
identyfikatorUżytkownika='ja'
).wykonaj()Ścieżka 3 - Zunifikowane API poczty e-mail (Pomiń OAuth Boilerplate)
Jeśli Twoim celem jest odczytywanie, wysyłanie lub synchronizowanie poczty e-mail w produkcyjnej aplikacji SaaS i wolisz nie poświęcać cykli inżynieryjnych na zarządzanie infrastrukturą OAuth, ujednolicone API poczty e-mail, takie jak Unipile, abstrahuje całą warstwę uwierzytelniania. Zrozum jak działa synchronizacja poczty e-mail pod maską, albo przejść od razu do kodu. Takie podejście zapewnia również dostęp do Gmaila, Outlooka i IMAP w ramach jednego API – bez konieczności osobnej integracji dla każdego dostawcy.
Nie jest wymagana konfiguracja Google Cloud
Brak identyfikatora klienta OAuth, ekranu zgody ani przeglądu zakresu w Google. Własna zweryfikowana aplikacja OAuth Unipile obsługuje autoryzację użytkownika.
Automatyczna rotacja tokenów
Tokeny dostępu i tokeny odświeżania są w całości zarządzane przez Unipile. Twoja baza danych nigdy nie przechowuje tokena Google OAuth.
Działa z prywatnym Gmail + Outlook + IMAP
Jedno API, trzy uniwersa dostawców. Kiedy Ty porównaj dostawców API synchronizacji poczty e-mail, wsparcie dla wielu dostawców jest kluczowym wyróżnikiem.
Dostarczanie webhooków dla nowych wiadomości
Zamiast odpytywać API Gmaila, Unipile wysyła nowe zdarzenia e-mail do Twojego punktu końcowego webhooka w czasie rzeczywistym, na połączone konto.
// 3 linie do odczytu skrzynki Gmail przez Unipile
// Brak konfiguracji OAuth, brak zarządzania tokenami
const { UnipileClient } = require('unipile-node-sdk');
const klient = nowy UnipileClient({
token: process.env.UNIPILE_API_KEY
});
// Wyświetl e-maile z połączonego konta Gmail
// accountId = identyfikator połączonego konta Unipile
const e-maile = czekać client.email.listMessages({
account_id: 'identyfikator-połączonego-konta',
limit: 20
});
// Wyślij e-mail w imieniu połączonego konta
czekać client.email.wysyłać({
account_id: 'identyfikator-połączonego-konta',
to: 'recipient@example.com',
temat: 'Cześć z Unipile',
body: 'Nie widać tokenu OAuth.'
});
// Działa identycznie dla Outlook i IMAP
// Po prostu zamień account_idStwórz swoją integrację Gmail bez operacji OAuth
Zacznij od Kompletny przewodnik po integracji z Gmail API, następnie wdrożenie z Unipile jako warstwą uwierzytelniania i synchronizacji.
Częste błędy podczas próby użycia klucza API z Gmail
Jeśli trafiłeś do tego artykułu, ponieważ Twoje wywołanie API Gmail nie powiodło się, oto dwa błędy, z którymi się zetkniesz i co dokładnie każdy z nich oznacza – wraz z pierwotną treścią odpowiedzi, abyś mógł je natychmiast rozpoznać.
Wysłano żądanie do interfejsu API Gmail z kluczem API (?klucz=AIza...) lub w ogóle bez autoryzacji. Gmail API wymaga prawidłowego tokena dostępu OAuth 2.0 w Autoryzacja: Bearer Nagłówek. To jest pierwszy błąd, który zobaczysz podczas pierwszego eksperymentowania z kluczem API.
Napraw Zaimplementuj jedną z 3 powyższych ścieżek uwierzytelniania. Klucz API nie jest rozwiązaniem – potrzebujesz tokena dostępowego OAuth.
HTTP/1.1 401 Nieautoryzowany
Content-Type: application/json
"code": 401,
"message": "W żądaniu brakuje wymaganego poświadczenia uwierzytelnienia. Oczekiwano tokena dostępu OAuth 2, pliku cookie logowania lub innego prawidłowego poświadczenia uwierzytelnienia. Patrz https://developers.google.com/identity/sign-in/web/...",
"status": "UNAUTHENTICATED",
"errors": [{
"message": "Wymagane zalogowanie",
"domain": "googleapis.com",
"reason": "required",
"location": "Authorization",
"locationType": "header"
}]
}
}Po wielokrotnych nieautoryzowanych żądaniach (nawet z kluczem API), system limitów Google blokuje dalsze nieautoryzowane wywołania z Twojego IP lub projektu. Nie jest to limit żądań dla uwierzytelnionych użytkowników – oznacza to konkretnie Twoje prośby nigdy nie zostały uwierzytelnione i wyczerpałeś(aś) swój niewielki darmowy limit anonimowych połączeń.
Napraw Tak samo jak powyżej - Twoje podejście z kluczem API nigdy nie zadziała. Użyj tokenów dostępu OAuth 2.0. Ten błąd zniknie, gdy Twoje żądania będą zawierać prawidłowy token typu Bearer.
HTTP/1.1 403 Zakazano
Content-Type: application/json
"code": 403,{
"message": "Przekroczono dzienny limit dla użycia bez uwierzytelnienia. Dalsze użycie wymaga rejestracji.",
"status": "RESOURCE_EXHAUSTED",
"errors": [
{
"message": "Przekroczono dzienny limit dla użycia bez uwierzytelnienia.",
"domain": "usageLimits",
"reason": "dailyLimitExceededUnreg"
}
]
}Pola zakresu dla Gmail API, których faktycznie będziesz potrzebować
Gdy już zaakceptujesz, że protokół OAuth jest wymagany, kolejną kluczową decyzją jest wybór zakresu. Google klasyfikuje zakresy Gmaila na trzy poziomy w zależności od wrażliwości ujawnianych danych. Żądanie większej liczby zakresów niż potrzebne wyzwala dłuższy proces weryfikacji, a w niektórych przypadkach pełną ocenę bezpieczeństwa przez Google.
Czułe zakresy (żółty) Wymagaj od Google przeglądu ekranu zgody OAuth i weryfikacji polityki prywatności Twojej aplikacji. Ograniczone zakresy (czerwony) wymaga formalnej oceny bezpieczeństwa, demonstracji wideo, a czasem audytu bezpieczeństwa przeprowadzonego przez stronę trzecią. Zaplanuj minimum 2-6 tygodni na zatwierdzenie ograniczonego zakresu. Jeśli korzystasz z Unipile jako warstwy uwierzytelniania, ten proces weryfikacji spoczywa na Unipile, a nie na Twojej aplikacji.
| Zakres | Poziom dostępu | Poziom | Przypadek użycia |
|---|---|---|---|
| gmail.tylko_do_odczytu | Przeczytaj wszystkie wiadomości, wątki, etykiety, ustawienia | Wrażliwy | Analityka e-mail, narzędzia do audytu skrzynki odbiorczej, synchronizacja z CRM (tylko do odczytu) |
| gmail.wyślij | Wyślij e-mail w imieniu użytkownika | Wrażliwy | Transakcyjne e-maile użytkownika, działania posprzedażowe CRM, narzędzia do kontaktów |
| gmail.pisz | Tworzenie, odczytywanie, aktualizowanie, usuwanie wersji roboczych; wysyłanie wiadomości | Wrażliwy | Integracje kompozytora wiadomości e-mail, zarządzanie wersjami roboczymi |
| gmail.zmodyfikuj | Czytaj, wysyłaj, modyfikuj (etykiety, archiwizuj) - bez usuwania | Ograniczony | Pełne zarządzanie skrzynką odbiorczą, synchronizacja CRM z zapisem, przepływy pracy archiwizacji |
| mail.google.com | Pełny dostęp – odczyt, zapis, usuwanie, ustawienia | Ograniczony | Wszechstronne klienty poczty elektronicznej, narzędzia do tworzenia kopii zapasowych, migracja administratorów |
| metadane gmail | Metadane wiadomości tylko (bez treści) | Niewrażliwy | Analityka wolumenu poczty e-mail, wzorców nadawca/odbiorca (bez treści) |
Budowanie aplikacji SaaS dla wielu najemców, która potrzebuje uprawnień gmail.modify lub mail.google.com? Ograniczony zakres przeglądu wydłuża harmonogram wdrożenia o tygodnie. Z Unipile pomijasz całkowicie przegląd ekranu zgody – zweryfikowana aplikacja OAuth Unipile obejmuje zakresy, których potrzebuje Twoja integracja.
Budowanie z UnipileDrzewo decyzyjne: Która metoda uwierzytelniania dla Twojego przypadku użycia?
Odpowiedz na trzy pytania, a dowiesz się dokładnie, która ścieżka uwierzytelniania Gmail API pasuje do Twojego projektu. Nie ma uniwersalnej odpowiedzi – każda ścieżka rozwiązuje inny problem. Aby uzyskać pełną Kompletny przewodnik po integracji z Gmail API, kontynuuj do poczty Gmail. Aby odpowiednik dla Outlook / Microsoft 365, zobacz nasz przewodnik OAuth Microsoft Graph.
Aplikacja SaaS, w której klienci łączą swoje własne Gmail.
Czy twoi użytkownicy są zewnętrzni (nie twoi pracownicy)?
Tak – to twoi klienci z osobistymi kontami Gmail lub Google Workspace.
Czy musisz obsługiwać wiele różnych domen Google?
Tak, wielodostępny. Każdy użytkownik podłącza swoje własne konto.
Lub Ścieżka 3 (Zunifikowane API) aby całkowicie pominąć infrastrukturę OAuth.
Narzędzie wewnętrzne dla Twojej organizacji Google Workspace
Czy wszyscy użytkownicy należą do tej samej domeny Workspace (Twoi pracownicy)?
Tak – tylko konta firmy company.com. Brak zewnętrznych użytkowników Gmail.
Czy masz administratora Workspace, który może skonfigurować DWD?
Tak - dostęp administracyjny dostępny w admin.google.com.
Brak przepływów zgód dla poszczególnych użytkowników. Administrator deleguje raz.
Aplikacja SaaS potrzebująca Gmail + Outlook + IMAP pod jednym API
Czy państwa użytkownicy mają mieszankę kont Gmail, Outlook i IMAP?
Tak – nie można przewidzieć, z którym dostawcą połączy się każdy użytkownik.
Czy chcesz unikać uruchamiania oddzielnych integracji OAuth na dostawcę?
Tak – zarządzanie Google OAuth, Microsoft OAuth i IMAP to zbyt duża złożoność.
Jeden klucz API. Gmail, Outlook, IMAP. Bez operacji OAuth.
Rozpocznij tworzenie integracji z Gmail już dziś
Niezależnie od wybranej ścieżki, Unipile daje Ci Przegląd ujednoliconego API poczty e-mail aby zrozumieć architekturę przed podjęciem decyzji o jednym podejściu. Albo od razu przejdź do pulpitu nawigacyjnego i połącz swoje pierwsze konto w kilka minut.
Często zadawane pytania
Najczęstsze pytania dotyczące uwierzytelniania Gmail API, kluczy API w porównaniu do tokenów OAuth oraz programowego dostępu do Gmail bez samodzielnego zarządzania OAuth.
Czy mogę użyć klucza API Google do uzyskania dostępu do Gmaila?
Nie. Klucze API Google działają tylko dla publicznych, niezwiązanych z konkretnym użytkownikiem API, takich jak Mapy, Tłumacz czy YouTube Data (publiczna zawartość). API Gmaila uzyskuje dostęp dane prywatnej skrzynki pocztowej użytkownika, wymaga jawnej zgody użytkownika za pośrednictwem protokołu OAuth 2.0. Wysłanie żądania do interfejsu API Gmaila przy użyciu samego klucza API zwraca 401 Wymagane logowanie lub Przekroczono 403 dzienny limit dla użytku nieautoryzowanego błąd – za każdym razem bez wyjątku.
Czy interfejs API Gmail wymaga OAuth 2.0?
Tak, zawsze. Dostęp do Gmail API jest dostępem do danych użytkownika, co oznacza, że każde żądanie musi być powiązane z uwierzytelnionym użytkownikiem, który udzielił zgody za pośrednictwem przepływu OAuth 2.0. Nie ma obejścia: żaden klucz API, żadne uwierzytelnianie podstawowe (przestarzałe wrzesień 2024), brak magicznego nagłówka. Trzy obsługiwane ścieżki uwierzytelniania to: Identyfikator klienta OAuth 2.0 (wielodostawcowy), Konto usługi z delegacją w całej domenie (tylko Workspace) oraz zunifikowane API poczty e-mail, takie jak Unipile, które obsługuje warstwę OAuth za Ciebie.
Jaka jest różnica między kluczem API a identyfikatorem klienta OAuth w Google Cloud?
An Klucz API identyfikuje Twój projekt Google Cloud na potrzeby rozliczeń i limitów. Działa tylko w przypadku interfejsów API udostępniających dane publiczne (Mapy, Tłumacz itp.). Identyfikator klienta OAuth służy do zainicjowania przepływu zgody, w którym rzeczywisty użytkownik zatwierdza dostęp Twojej aplikacji do swojego konta. Identyfikator klienta OAuth generuje token dostępu i token odświeżania, które faktycznie akceptuje interfejs API Gmaila. Są to dwa całkowicie różne mechanizmy: jeden identyfikuje projekt, drugi uwierzytelnia użytkownika.
Czy konto usługi może odczytywać Gmail bez zgody użytkownika?
Tylko jeśli Delegowanie w całej domenie jest włączona przez administratora Google Workspace. Samo konto usługi nie może uzyskać dostępu do żadnej skrzynki odbiorczej Gmail. Po skonfigurowaniu DWD konto usługi może podszywać się pod dowolnego użytkownika w organizacji i uzyskać dostęp do jego skrzynki pocztowej bez interaktywnej zgody. Krytyczne ograniczenie: działa to tylko w przypadku kont Google Workspace (firmowych). Nie działa w przypadku osobistych adresów Gmail (@gmail.com. Zobacz Oficjalna dokumentacja DWD Google.
Dlaczego Gmail API zwraca "Login Required" z moim kluczem API?
Ponieważ Gmail API nie akceptuje kluczy API. The 401 Wymagane logowanie błąd oznacza, że w żądaniu brakuje prawidłowego tokenu dostępu OAuth 2.0 w Authorization Nagłówek. Gmail API oczekuje: Autoryzacja: Bearer {access_token} - gdzie token dostępu został uzyskany za pomocą przepływu OAuth 2.0 (kod autoryzacji, JWT konta usługi lub zunifikowany token API). Prostym dodaniem ?klucz=TWÓJ_KLUCZ_API do adresu URL interfejsu API Gmail nie zadziała i zwróci błąd 401 lub 403.
Czy jest sposób, aby używać Gmail API bez samodzielnego zarządzania OAuth?
Tak. Jedno ujednolicone API emailowe takie jak Unipile obsługuje całą warstwę OAuth: ekran zgody, wymianę tokenów i ciche odświeżanie tokenów. Twoja aplikacja nigdy nie przechowuje ani nie zarządza tokenami dostępu ani tokenami odświeżania. Wywołujesz API Unipile za pomocą własnego klucza API, a Unipile zarządza całą komunikacją OAuth z Google w imieniu Twojej połączone konta. Usuwa to proces zatwierdzania ekranu zgody Google oraz złożoność zarządzania tokenami z Twojego kodu - i daje Ci Gmail, Outlook i IMAP w jednym, zunifikowanym interfejsie.
PL 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
TR