LinkedIn
Instagram
WhatsApp
Telegram
Kalendarz Google
Dołącz do społeczności SlackGoogle OAuth Weryfikacja & Dane uwierzytelniające API Gmail
Krok po kroku: utwórz dane logowania OAuth do Gmail API, przejdź weryfikację aplikacji Google i przegląd CASA Tier 2 – lub dostarcz dziś, korzystając z już certyfikowanego klucza OAuth Unipile i certyfikuj swój własny później.
Całkowicie pomiń konfigurację Google Cloud.Klucz OAuth certyfikowany przez Unipile się tym zajmuje. const response = czekać fetch('https://api.unipile.com/api/v1/hosted/accounts', { method: 'POST', nagłówki: { 'Klucz API X': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ typ: 'GOOGLE', imię: 'użytkownik-123', ważne do: '2026-12-31' })}); const { adres url } = czekać odzew.json();// Przekieruj użytkownika do `url` - zrobione.Czym właściwie jest weryfikacja Google OAuth
Weryfikacja Google OAuth to formalny proces zatwierdzania, za pomocą którego Google potwierdza, że Twoja aplikacja przetwarza dane użytkowników zgodnie z jego zasadami. Dopóki Twoja aplikacja nie przejdzie tej weryfikacji, jest ona uważana za niezweryfikowaną, co oznacza, że użytkownicy widzą ekran ostrzeżenia, a Ty jesteś ograniczony do maksymalnie 100 użytkowników testowych. Weryfikacja jest obowiązkowa za każdym razem, gdy Twoja aplikacja żąda wrażliwych lub ograniczonych zakresów Gmail API od użytkowników zewnętrznych (niebędących wewnętrznymi).
Wrażliwe zakresy: czym są
Wrażliwe zakresy pozwalają aplikacji na odczytywanie lub modyfikowanie danych użytkownika wykraczających poza podstawowe informacje profilowe. W przypadku Gmaila obejmują one:
gmail.tylko_do_odczytu- przeczytaj wszystkie wiadomościgmail.wyślij- wyślij e-mail w imieniu użytkownikagmail.zmodyfikuj- czytać, pisać, archiwizowaćmail.google.com- pełny dostęp (ograniczony)
Wrażliwe zakresy wymagają oceny bezpieczeństwa Google. Ograniczone zakresy (takie jak pełny dostęp do IMAP) dodatkowo wymagają audytu CASA poziomu 2. Pełne odniesienie do zakresów znajduje się w naszym Przewodnik po zakresach Gmail API.
Dlaczego Gmail API zawsze to wyzwala
W przeciwieństwie do podstawowego przepływu logowania przez Google (który żąda jedynie danych profilowych), interfejs Gmail API zawsze żąda zakresów, które udzielają dostępu do zawartości skrzynki odbiorczej użytkownika. Google traktuje wszelkie uprawnienia na poziomie skrzynki pocztowej jako wrażliwe z definicji.
Oznacza to, że każdy deweloper chcący korzystać z Gmail API dla zewnętrznych użytkowników musi przejść weryfikację aplikacji Google OAuth – nie istnieje wersja Gmail API, która omija ten wymóg przy użytku produkcyjnym.
Nie wiesz, czy potrzebujesz poświadczeń OAuth, czy prostego klucza API? Przeczytaj nasz Klucz API Gmail vs OAuth - przewodnik.
Kluczowe rozróżnienie: Weryfikacja Google OAuth nie jest jednorazowym wydarzeniem. Jeśli dodasz nowe zakresy uprawnień (scopes) do już zweryfikowanej aplikacji, musisz ponownie przesłać aplikację do przeglądu, uwzględniając te dodatkowe zakresy. Zaplanuj strategię dotyczącą zakresów przed rozpoczęciem procesu – pozwoli to zaoszczędzić tygodnie pracy.
Tygodnie weryfikacji.
Użycie Klucz Unipile i zacznij teraz.
Nie trać klientów przez czekanie na recenzje Google. Połącz konta Gmail w 5 minut dzięki naszym wstępnie zweryfikowanym danym deweloperskim.
Jak uzyskać dane uwierzytelniające API Gmail: krok po kroku
Uzyskanie poświadczeń OAuth dla Gmail API wymaga sześciu odrębnych kroków w Google Cloud Console. Oto pełna sekwencja – od utworzenia projektu do uzyskania działającego client_id oraz client_secret.
- Utwórz projekt Google Cloud - Twój izolowany kontener rozliczeniowy i API.
- Włącz interfejs API Gmail - aktywuj interfejs API w Bibliotece interfejsów API dla swojego projektu.
- Skonfiguruj ekran zgody OAuth - wybierz typ aplikacji (zewnętrzna vs wewnętrzna), wypełnij nazwę aplikacji, adres e-mail wsparcia i autoryzowane domeny.
- Dodaj zakresy - zaznacz zakresy Gmail, których potrzebuje Twoja aplikacja; określa to, czy wymagana jest weryfikacja bezpieczeństwa.
- Utwórz identyfikator klienta OAuth - wybierz typ aplikacji (Web, Desktop lub iOS/Android) i zarejestruj swoje adresy URI przekierowania.
- Prześlij do weryfikacji - jeśli Twoja aplikacja jest zewnętrzna i korzysta z wrażliwych zakresów, prześlij ją za pośrednictwem portalu weryfikacyjnego Google.
Idź do console.cloud.google.com, kliknij selektor projektu w górnym pasku nawigacyjnym i wybierz "Nowy projekt". Nadaj mu nazwę odzwierciedlającą Twój produkt – pojawi się ona na ekranie zgody OAuth, który widzą użytkownicy.
Włącz rozliczenia dla projektu, nawet jeśli spodziewasz się, że nie przekroczysz limitów bezpłatnych. Wiele interfejsów API (w tym Gmail) wymaga powiązania konta rozliczeniowego przed ich aktywacją, nawet przy wykorzystaniu $0.
Google Cloud Console: utwórz nowy projekt za pomocą wybieraka projektów na górnym pasku nawigacyjnym.
W konsoli Google Cloud przejdź do sekcji "API i usługi" > "Biblioteka". Wyszukaj "Gmail API" i kliknij "Włącz". Prawdopodobnie będziesz chciał także włączyć interfejs Google People API, jeśli potrzebujesz danych kontaktowych oprócz poczty e-mail.
Po włączeniu interfejs API Gmail pojawi się na Twoim pulpicie nawigacyjnym "Włączone interfejsy API". Wywołania interfejsu API bez prawidłowych poświadczeń zwrócą w 403 dostępNieSkonfigurowany błąd już na tym etapie - dalej są poświadczenia.
Biblioteka Google API: wyszukaj frazę "Gmail API" i kliknij „Włącz”, aby aktywować ją dla swojego projektu.
Przejdź do "Interfejsów API i usług" > "Ekran zgody OAuth". Wybierz swój typ użytkownika:
- Wewnętrzny - tylko użytkownicy w danej organizacji Google Workspace. Nie jest wymagana weryfikacja.
- Zewnętrzny - dowolne konto Google. Weryfikacja wymagana dla wrażliwych/ograniczonych zakresów poza 100 użytkownikami testowymi.
Ekran zgody OAuth: wybierz typ użytkownika Wewnętrzny (tylko Workspace) lub Zewnętrzny (dowolne konto Google).
Nazwa aplikacji, E-mail wsparcia użytkownika i e-mail kontaktowy dewelopera. Te pola pojawiają się na ekranie zgody, który użytkownicy widzą podczas autoryzacji Twojej aplikacji. Dodaj swój autoryzowany domen (domenę strony głównej i adresu URL polityki prywatności).
Szczegółowe omówienie każdego pola, limitu 100 użytkowników i wyboru Wewnętrzny vs Zewnętrzny znajdziesz w naszym Poradnik konfiguracji ekranu zgody.
Informacje o aplikacji: wpisz nazwę aplikacji, logo i adres e-mail pomocy technicznej dokładnie tak, jak powinny się pojawić na ekranie zgody.
Dziedzina aplikacji: podaj aktywne adresy URL swojej strony głównej, polityki prywatności i warunków korzystania z usługi. Zespół weryfikacyjny Google sprawdza te dane.
Domeny autoryzowane: dodaj domenę główną swojej aplikacji. Tylko identyfikatory URI z tej domeny mogą być używane jako identyfikatory URI przekierowania.
Dane kontaktowe dewelopera: Google używa tego adresu e-mail do powiadamiania o zmianach w statusie weryfikacji Twojej aplikacji.
Wskazówka: Sekcja "Domena aplikacji" akceptuje wiele linków (Strona główna, Polityka prywatności, Warunki korzystania z usługi). Zespół weryfikacyjny Google sprawdzi, czy te adresy URL są aktywne i czy odzwierciedlają żądane zakresy. Brakujący lub uszkodzony adres URL polityki prywatności jest jednym z najczęstszych powodów odrzucenia weryfikacji.
W konfiguracji ekranu zgody kliknij "Dodaj lub usuń zakresy". Użyj filtra, aby znaleźć zakresy Gmail. Wybrany zakres ma bezpośredni wpływ na ścieżkę weryfikacji:
gmail.wyślijlubgmail.tylko_do_odczytu- wrażliwy, wymaga oceny bezpieczeństwa.gmail.zmodyfikujlubmail.google.com- Ograniczone, wymaga dodatkowo CASA Tier 2.openid email profiltylko - bez weryfikacji (podstawowe logowanie).
Dodaj lub usuń zakresy: wybierz zakresy Gmail, których wymaga Twoja aplikacja. Wybór zakresów bezpośrednio określa ścieżkę weryfikacji.
Dokładnie zaplanuj wybór zakresu. Dodanie ograniczonego zakresu później oznacza ponowne przesłanie całej aplikacji do dodatkowej recenzji CASA Tier 2. Pełny zakres oraz API odblokowywane przez każdy zakres znajdują się w naszym Przewodnik po zakresach Gmail API.
Przejdź do "API i usługi" > "Dane uwierzytelniające" > "Utwórz dane uwierzytelniające" > "Identyfikator klienta OAuth". Wybierz typ swojej aplikacji:
- Aplikacja internetowa - dla aplikacji po stronie serwera. Zarejestruj swoje adresy URI przekierowania (np.
https://yourapp.com/oauth/callback). - Aplikacja na pulpit - dla zainstalowanych aplikacji. Wykorzystuje przekierowanie zwrotne.
- iOS / Android - aplikacje mobilne, wykorzystują niestandardowe schematy URI.
Panel poświadczeń: wybierz "Identyfikator klienta OAuth", aby wygenerować identyfikator klienta (client_id) i klucz tajny klienta (client_secret), których potrzebuje Twoja aplikacja.
Po utworzeniu pobierz plik poświadczeń JSON. Zawiera on twoje client_id, client_secret, i zarejestrowane identyfikatory URI przekierowania. Przechowuj go bezpiecznie – nigdy nie umieszczaj go w kontroli wersji.
Głębokie zanurzenie w różnice między tym typem poświadczeń a prostym kluczem API znajdziesz w naszym Klucz API Gmail a dane uwierzytelniające OAuth — przewodnik.
Tokeny dostępu i tokeny odświeżania: po zakończeniu przepływu OAuth, otrzymujesz krótkotrwały token_dostępu (ważny ~1 godzinę) i a token_odświeżający (długo żyjący, przechowywany po stronie serwera). Twój serwer używa tokena odświeżającego do uzyskania nowych tokenów dostępu bez ponownego podawania hasła przez użytkownika. Zawsze żądaj typ_dostępu=offline oraz zgoda przy pierwszej autoryzacji, aby otrzymać token odświeżający. Przechowuj tokeny odświeżające zaszyfrowane w spoczynku.
Aby uzyskać szerszy obraz sposobu, w jaki OAuth pasuje do architektury API poczty e-mail – w tym strategii synchronizacji i różnic między dostawcami – zapraszamy do zapoznania się z naszym Przewodnik po interfejsie API OAuth Email.
Użyj klucza UnipileOstrzeżenie "Ta aplikacja nie została zweryfikowana", limit 100 użytkowników i zwolnienia
Zanim Twoja aplikacja przejdzie weryfikację weryfikacji aplikacji Google OAuth, każdy użytkownik próbujący ją autoryzować zobaczy ekran ostrzegawczy. Google narzuca również twardy limit 100 użytkowników na niezweryfikowane aplikacje zewnętrzne. Oto dokładne znaczenie i kiedy się nie stosuje.
Na ekranie widnieje napis: "Ta aplikacja nie została zweryfikowana. Ta aplikacja nie została zweryfikowana przez Google. Może ona żądać dostępu do wrażliwych informacji. Dowiedz się o ryzyku". Użytkownicy muszą kliknąć "Zaawansowane", a następnie "Przejdź do [Nazwa aplikacji] (niebezpieczne), aby kontynuować. Większość nietechnicznych użytkowników zatrzyma się tutaj – to jest rzeczywisty koszt pominięcia lub opóźnienia weryfikacji.
Kiedy weryfikacja aplikacji Google OAuth NIE jest wymagana
Tylko do użytku wewnętrznego
Jeśli ustawisz swój ekran zgody OAuth na "Wewnętrzny", a Twoja aplikacja obsługuje tylko użytkowników w Twojej organizacji Google Workspace, weryfikacja nie jest wymagana – niezależnie od tego, jakie zakresy żądasz. Jest to najszybsza ścieżka dla narzędzi wewnętrznych.
Tryb testowy (poniżej 100 użytkowników)
Niezweryfikowana zewnętrzna aplikacja może mieć dodanych do 100 użytkowników testowych za pośrednictwem Konsoli Google Cloud. Ci konkretni użytkownicy mogą autoryzować aplikację bez blokady - widzą ostrzeżenie, ale mogą kontynuować. Przydatne do tworzenia i prywatnej bety z małym zespołem.
Tylko podstawowe zakresy
Jeśli Twoja aplikacja żąda jedynie nieczułych zakresów (openid, email, profile – podstawowe logowanie przez Google), weryfikacja nie jest wymagana nawet dla użytkowników zewnętrznych, niezależnie od skali. Weryfikacja jest uruchamiana specjalnie w przypadku żądania czułych i ograniczonych zakresów.
Ważne ramy: Celem limitu 100 użytkowników i ekranu ostrzegawczego jest ochrona użytkowników podczas przeglądu aplikacji. Prawidłową reakcją na osiągnięcie limitu jest przesłanie aplikacji do weryfikacji aplikacji Google OAuth – a nie tworzenie wielu projektów Google Cloud w celu rozłożenia użytkowników. Google wyraźnie zabrania takiego podejścia, a może ono skutkować zawieszeniem Twojego konta deweloperskiego. Zgodną ścieżką jest albo weryfikacja aplikacji, albo skorzystanie z platformy, która już udostępnia zweryfikowany klucz OAuth, takiej jak Unipile.
Weryfikacja aplikacji Google: harmonogram i koszty w 2026 roku
Weryfikacja aplikacji Google nie jest pojedynczym procesem – posiada trzy odrębne ścieżki, w zależności od tego, jakie zakresy żąda Twoja aplikacja. Każda ścieżka ma swój własny harmonogram i koszt. Oto, czego można się spodziewać w 2026 roku.
Jeśli Twoja aplikacja korzysta wyłącznie z niepoufnych zakresów (podstawowe logowanie przez Google), Google może nadal wymagać weryfikacji marki, aby potwierdzić tożsamość Twojej aplikacji i domenę strony głównej. Zazwyczaj jest to proces trwający 2-3 dni robocze, bezpłatny poza Twoim czasem.
Będziesz musiał zweryfikować własność domeny za pomocą Google Search Console i upewnić się, że Twój ekran zgody OAuth dokładnie opisuje Twoją aplikację.
Aplikacje żądające wrażliwych zakresów Gmail muszą przejść pełną ocenę bezpieczeństwa Google. Zespół Google weryfikuje praktyki aplikacji dotyczące obsługi danych, politykę prywatności i uzasadnienie każdego żądanego zakresu.
Typowy czas realizacji to 2-4 tygodnie po ukończeniu przesłania. Niekompletne zgłoszenia (brak polityki prywatności, niejasne uzasadnienia zakresu, niedopasowane autoryzowane domeny) powodują ponowne rozpoczęcie odliczania. Google może poprosić o demonstrację lub dodatkową dokumentację w tym okresie.
Aplikacje żądające ograniczonych zakresów - głównie https://mail.google.com/ (pełny dostęp IMAP) - musi ukończyć Ocena bezpieczeństwa CASA poziomu 2 Oprócz własnego przeglądu Google. CASA (Cloud Application Security Assessment) to niezależny audyt bezpieczeństwa przeprowadzany przez zatwierdzone przez Google laboratorium.
W 2026 roku Google oferuje ścieżka samoobsługowa CASA Tier 2 przez zatwierdzone laboratoria, zazwyczaj kosztujące $540–$1000 (opłaty laboratoryjne za zautomatyzowane skanowanie). Jest to znaczące ulepszenie w stosunku do starego systemu. Starsza, ręcznie sterowana ocena bezpieczeństwa, której wcześniej wymagał Google dla tej samej klasy zakresu, kosztowała $15 000–$75 000 i zajmowało miesiące – ten tradycyjny tor nadal ma zastosowanie do niektórych aplikacji objętych klauzulą dziadka oraz w skrajnych przypadkach korporacyjnych. Podczas ustalania budżetu skonsultuj się z wybranym laboratorium, aby ustalić, który tor ma zastosowanie do Twojej aplikacji.
Całkowity harmonogram, wliczając własną ocenę Google po CASA: 4-12 tygodni od pierwszego złożenia do zatwierdzenia.
Podsumowanie kosztów: weryfikacja aplikacji Google OAuth w 2026 r.
| Ścieżka weryfikacyjna | Zakres poziomu | Oś czasu | Koszt |
|---|---|---|---|
| Weryfikacja marki | Niejawne (openid, email, profile) | 2-3 dni robocze | Darmowy |
| Ocena bezpieczeństwa | Wrażliwe (gmail.send, gmail.readonly, gmail.modify) | 2-4 tygodnie | Darmowy |
| CASA Poziom 2 (samoobsługa, 2026) | Ograniczony (mail.google.com) | 4-8 tygodni | ~$540–$1 000 |
| CASA Tier 2 (przestarzała instrukcja, przed 2025) | Ograniczony (mail.google.com) | 8-12 tygodni | $15k–$75k |
Źródła: Polityki Google OAuth 2.0 (developers.google.com) i Google Cloud - weryfikacja aplikacji OAuth - omówienie (support.google.com). Ceny w ramach samoobsługowego programu CASA Tier 2 opierają się na zatwierdzonych stawkach laboratoryjnych obowiązujących od I kwartału 2026 r. i mogą się różnić w zależności od laboratorium oraz liczby aplikacji objętych programem. Dotychczasowy model cenowy $15k-$75k miał zastosowanie do aplikacji, które przeszły poprzedni obowiązkowy program oceny bezpieczeństwa realizowany przez dostawców Google, zanim udostępniono opcję samoobsługową CASA.
Nie czekajTypowe błędy Google OAuth, na które natkniesz się
Kiedy zarządzasz własnym projektem Google Cloud, podczas tworzenia i po jego wdrożeniu pojawia się kilka powtarzających się błędów. Oto szybki podręcznik z najczęstszymi z nich.
URI przekierowania w Twoim żądaniu nie jest dokładnym dopasowaniem jednego zarejestrowanego w Google Cloud Console (protokół, ukośnik końcowy i port mają znaczenie).
Administrator Google Workspace zablokował aplikacje OAuth innych firm lub ograniczył zakresy, o które prosi Twoja aplikacja.
Twoja aplikacja korzysta z poufnych lub ograniczonych zakresów, ale nie przeszła procesu weryfikacji Google, dlatego Google blokuje zgodę dla nowych użytkowników.
Token odświeżania wygasł lub został unieważniony (użytkownik zmienił hasło, unieważnił dostęp, lub token był nieaktywny przez 6 miesięcy). Użytkownik musi ponownie się uwierzytelnić.
Ekran zgody jest nieprawidłowo skonfigurowany w Google Cloud Console: zły typ użytkownika (wewnętrzny vs zewnętrzny), brak użytkowników testowych lub aplikacja jest nadal w stanie wersji roboczej.
Ciąg zakresu zawiera literówkę lub odpowiednie API (np. Gmail API) nie zostało włączone w Google Cloud Console dla Twojego projektu.
Potrzebujesz pełnej diagnozy? Każdy z tych błędów ma specyficzne rozwiązanie. Zobacz nasz pełny przewodnik po typowe błędy Google OAuth i Gmail API oraz jak je naprawić.
Gdy OAuth jest obsługiwane przez Unipile, niezależnego pośrednika technicznego działającego w imieniu każdego uwierzytelnionego użytkownika, błędy te są zarządzane na poziomie API. Unipile posiada już certyfikat CASA Tier 2, dzięki czemu przeszkody weryfikacyjne są pokonywane raz, a nie raz dla każdego projektu.
Tygodnie weryfikacji.
Użycie Klucz Unipile i zacznij teraz.
Nie trać klientów przez czekanie na recenzje Google. Połącz konta Gmail w 5 minut dzięki naszym wstępnie zweryfikowanym danym deweloperskim.
Google OAuth, Uproszczone: Zrób to sam vs zarządzane - wdrażaj teraz czy czekaj tygodniami?
Jeśli Twoja aplikacja potrzebuje dostępu do Gmaila dla użytkowników zewnętrznych, stajesz przed dwoma ścieżkami: uruchomienie własnego projektu Google Cloud i przejście pełnego procesu weryfikacji aplikacji Google OAuth (6-12 tygodni) lub zbudowanie na platformie posiadającej już klucz OAuth z certyfikatem CASA Tier 2 (1-2 dni). Oto jak wygląda każda ścieżka i dlaczego nie wykluczają się wzajemnie.
Strategiczna lektura: Ścieżka DIY ma sens długoterminowo, jeśli chcesz mieć pełne prawo własności do swojej marki OAuth i ekranu zgody. Ścieżka zarządzana (Unipile) ma sens, gdy potrzebujesz szybkiego wdrożenia, chcesz ominąć limit 100 użytkowników lub odroczyć koszt CASA Tier 2. Te ścieżki nie wykluczają się wzajemnie – możesz dziś budować na Unipile i jednocześnie przeprowadzać własną certyfikację, a następnie przejść na własne poświadczenia (Bring Your Own Credentials), gdy Twoja aplikacja zostanie zweryfikowana.
Jeśli Twoje zastosowanie obejmuje wyłącznie Workspace (narzędzia wewnętrzne, automatyzacja HR, brak zgody użytkownika), alternatywą serwer-do-serwera jest konto usługi z delegowaniem na poziomie domeny - zobacz nasz Konto usługi Gmail i przewodnik DWD.
Uwaga dotycząca zgodności: Unipile jest niezależnym pośrednikiem technicznym, niepowiązanym z Google, niezatwierdzonym ani sponsorowanym przez Google. Klient OAuth Google firmy Unipile posiada certyfikat CASA Tier 2, umożliwiający użytkownikom autoryzację dostępu do Gmaila bez wyświetlania ostrzeżenia o "niezweryfikowanej aplikacji". Nie jest to obejście procesu weryfikacji bezpieczeństwa Google – weryfikacja nadal obowiązuje, jeśli tworzysz własną aplikację Google Cloud; Unipile już ją przeszedł dla połączeń, które pośredniczy w Twoim imieniu. Użytkownicy mogą w dowolnym momencie cofnąć dostęp na stronie uprawnień swojego Konta Google.
Testuj teraz na Unipile. certyfikowany klucz, certyfikuj równolegle, przełącz gdy gotowe
Nie musisz wybierać między szybką wysyłką a posiadaniem własnych danych uwierzytelniających Google. Unipile działa jako niezależny pośrednik techniczny – jego klient Google OAuth posiada już certyfikat CASA Tier 2 – dzięki czemu Twoi użytkownicy nigdy nie widzą ostrzeżenia o niezweryfikowanej aplikacji i nie ma limitu 100 użytkowników. Uruchom własną weryfikację aplikacji Google równolegle, a następnie w dowolnym momencie przełącz się na własne dane uwierzytelniające (Bring Your Own Credentials). Oto 3-etapowa podróż.
Test na certyfikowanym kluczu – wysyłka w minuty
Utwórz darmowe konto w Unipile i wygeneruj klucz API. Użyj hostowanego endpointu uwierzytelniania do wygenerowania adresu URL typu "one-link" dla każdego użytkownika. Przekieruj użytkownika na ten adres URL - ekran zgody OAuth Google w Unipile (już z certyfikatem CASA Tier 2) obsługuje autoryzację. Twój użytkownik nigdy nie zobaczy ostrzeżenia o "niezweryfikowanej aplikacji".
Po zakończeniu autoryzacji Unipile wysyła webhook na Twój serwer z identyfikatorem połączonego konta. Od tego momentu Twoja aplikacja może odczytywać, wysyłać i synchronizować Gmail za pośrednictwem ujednoliconego API Unipile. bez tworzenia ani jednego projektu Google Cloud.
// Krok 1: wygeneruj adres URL autoryzacji dla użytkownika z jednym łączem
const res = czekać fetch('https://api.unipile.com/api/v1/hosted/accounts', {
method: 'POST',
nagłówki: {
'Klucz API X': process.env.UNIPILE_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
typ: 'GOOGLE',
imię: 'użytkownik-456', // Twój wewnętrzny identyfikator użytkownika
ważne do: '2027-01-01',
notify_url: 'https://yourapp.com/webhooks/unipile'
})
});
const { adres url } = czekać rez.json();
// Przekieruj użytkownika pod adres `url` - Certyfikowany ekran zgody Unipile zajmie się resztą.Uruchom własną weryfikację Google OAuth równolegle
Gdy Twój produkt będzie działał, a użytkownicy będą aktywni, rozpocznij konfigurację własnego projektu w Google Cloud i prześlij aplikację do weryfikacji aplikacji Google OAuth. Postępuj zgodnie z powyższymi 5 krokami konfiguracji poświadczeń. Jeśli Twoja aplikacja korzysta z ograniczonych zakresów, zainicjuj samodzielną ocenę CASA Tier 2 za pośrednictwem laboratorium zatwierdzonego przez Google.
Jest bez pośpiechu do tego kroku, gdy korzystasz z certyfikowanego klucza Unipile - Twoi użytkownicy nie są blokowani, nie widzą żadnego ostrzeżenia i nie ma limitu użytkowników. Przeprowadź proces w tempie odpowiednim dla Twojego zespołu: zazwyczaj 2-4 tygodnie dla wrażliwych obszarów, 4-12 tygodni, jeśli wymagany jest CASA Tier 2.
Aby uzyskać wskazówki dotyczące wyboru zakresu, zobacz nasz Przewodnik po zakresach Gmail API - wybór minimalnych zakresów może przenieść Cię z ograniczonego (wymaganego przez CASA) toru do toru wrażliwego (bezpłatna ocena), oszczędzając czas i koszty.
Użyj własnych danych uwierzytelniających (BYOC) - jedna zmiana konfiguracji
Gdy Twoja aplikacja Google Cloud zostanie zweryfikowana i będziesz mieć własny client_id oraz client_secret, skonfiguruj Unipile, aby używało Twoich własnych poświadczeń OAuth do nowych połączeń kont. Jest to model Bring Your Own Credentials (BYOC): Unipile nadal działa jako niezależny pośrednik techniczny przetwarzanie żądań w imieniu każdego uwierzytelnionego użytkownika, korzystając teraz z Twoich zweryfikowanych danych uwierzytelniających zamiast udostępnionego klucza.
Istniejące połączone konta pozostają aktywne. Przełączenie dotyczy tylko nowych autoryzacji. Twoi użytkownicy widzą nazwę zweryfikowanej aplikacji na ekranie zgody, zastępując ekran z marką Unipile. Wybrałeś, kiedy zainwestować w weryfikację – nie od pierwszego dnia, kiedy potrzebowałeś wysłać.
Microsoft jest inny: dlaczego Azure nie potrzebuje przeglądu w stylu CASA
Jeśli twoja aplikacja musi uzyskać dostęp zarówno do Gmaila, jak i Outlooka, obciążenie związane z weryfikacją jest asymetryczne. Weryfikacja aplikacji Google OAuth – w tym potencjalny audyt CASA Tier 2 – dotyczy tylko Google. Podejście Microsoft Azure do rejestracji aplikacji i zgody OAuth ma odmienną architekturę i nie wymaga równoważnego zewnętrznego audytu bezpieczeństwa.
Każda aplikacja żądająca wrażliwych lub ograniczonych zakresów Gmail od użytkowników zewnętrznych musi przejść ocenę bezpieczeństwa Google. Ograniczone zakresy dodatkowo wymagają CASA Tier 2.
- Ostrzeżenie o niezweryfikowanej aplikacji wyświetlane użytkownikom
- Limit 100 użytkowników do weryfikacji
- Wymagany certyfikat CASA Tier 2 dla ograniczonych zakresów (~$540-$1k w trybie samoobsługowym)
- Wymagany ponowny przegląd po dodaniu nowych poufnych zakresów
- Oś czasu: 2-12+ tygodni, w zależności od poziomu zakresu
Azure Active Directory (obecnie Microsoft Entra ID) wykorzystuje model zgody administratora dla zakresów o wysokich uprawnieniach. Nie ma zewnętrznego wymogu audytu w stylu CASA dla standardowych zakresów dostępu do poczty.
- Brak ostrzeżenia o niezweryfikowanej aplikacji dla standardowych przepływów
- Brak limitu użytkowników podczas tworzenia
- Brak obowiązkowego zewnętrznego audytu bezpieczeństwa
- Wymagana zgoda administratora dla uprawnień w całym obszarze najemcy w środowiskach firmowych
- Microsoft 365 obejmuje zarówno osobisty program Outlook, jak i firmowy Exchange Online poprzez ten sam przepływ OAuth
Praktyczne zastosowanie dla aplikacji wielodostawców: Jeśli tworzysz produkt, który odczytuje pocztę z kont Gmail i Outlook, harmonogram weryfikacji Twojej aplikacji Google OAuth określa datę premiery, a nie harmonogram Microsoftu. Jest to jeden z najmocniejszych argumentów za korzystaniem z ujednoliconego API Unipile: obaj dostawcy są obsługiwani za pośrednictwem jednej integracji, a certyfikowany klucz Unipile pokrywa wymaganie CASA Tier 2 firmy Google od razu, usuwając je całkowicie z Twojej ścieżki krytycznej.
Aby uzyskać szczegółowe informacje na temat podejścia firmy Microsoft - w tym rejestracji aplikacji Azure, przepływów zgody i dostępu do interfejsu API Microsoft Graph - zobacz nasze Przewodnik OAuth po Microsoft Graph.
Jak Unipile zarządza Twoimi danymi
Unipile jest niezależnym pośrednikiem technicznym. Poniższe trzy notatki dokładnie wyjaśniają przepływ danych, co Unipile przechowuje oraz jakie są Twoje obowiązki jako klienta – w kontekście dostępu do Google OAuth i interfejsu Gmail API.
Co przechowuje Unipile – a czego nie
Unipile nie przechowuje równoległego archiwum ani niezależnej kopii danych Gmail użytkowników. Gdy aplikacja żąda danych poczty e-mail za pośrednictwem interfejsu API Unipile, Unipile pobiera je z serwerów Google. w imieniu uwierzytelnionego użytkownika i zwraca je do Twojej aplikacji. Dane są ściśle ograniczone do sesji uwierzytelnionego użytkownika i uprawnień, których udzielił podczas przepływu OAuth. Unipile nie przechowuje treści wiadomości poza tym, co jest niezbędne do przetworzenia odpowiedzi API.
Niezależny pośrednik techniczny - nie jest partnerem Google
Unipile działa jako niezależny pośrednik techniczny, działając w imieniu każdego uwierzytelnionego użytkownika, który udzielił dostępu za pośrednictwem ekranu zgody OAuth. Unipile jest nie powiązane z Google, nie zatwierdzone ani sponsorowane przez Google. Unipile nie udostępnia danych uwierzytelniających między użytkownikami – każde połączone konto używa własnych tokenów OAuth, ograniczonych do autoryzacji tego użytkownika. Twoja aplikacja uzyskuje dostęp do danych Gmail tylko dla użytkowników, którzy jawnie ukończyli przepływ OAuth i udzielili żądanych uprawnień.
Limity użycia Google obowiązują – decyzje o wykorzystaniu należą do Ciebie
Unipile przekazuje limity szybkości i ograniczenia kwotowe Gmail API Google do Twojej aplikacji. Gmail API egzekwuje dzienne limity na użytkownika (np. 250 jednostek kwoty na sekundę na użytkownika, 1 000 000 000 jednostek kwoty na dzień na projekt). Unipile wyświetla te limity, ale ich nie nadpisuje. Decyzje dotyczące częstotliwości żądań, ilości danych i zakresu zgód użytkownika pozostają w gestii decyzja po stronie klienta. Jesteś odpowiedzialny za zapewnienie, że korzystanie z danych Gmaila w Twojej aplikacji jest zgodne z Warunkami korzystania z API Google oraz oczekiwaniami użytkowników, zgodnie z ujawnionymi w Twojej polityce prywatności.
Aby uzyskać pełny przegląd możliwości interfejsu API poczty e-mail - w tym wysyłania, odczytu i synchronizacji w Gmailu, Outlooku i IMAP - zobacz nasze Przewodnik po API poczty elektronicznej.
Budowanie z UnipileGoogle OAuth dla deweloperów – Najczęściej zadawane pytania
Odpowiedzi na najczęstsze pytania dotyczące weryfikacji aplikacji Google OAuth, poświadczeń API Gmail i zarządzanego OAuth poprzez Unipile.
Twoja aplikacja potrzebuje weryfikacji aplikacji Google OAuth, jeśli jest ustawiona na Zewnętrzny typ użytkownika na ekranie zgody OAuth i żąda od użytkowników spoza Twojej organizacji Google Workspace dowolnych poufnych lub zastrzeżonych zakresów Gmail. Jeśli Twoja aplikacja żąda tylko podstawowych zakresów (openid, e-mail, profil) lub ustawiony na Internal, nie jest wymagana żadna weryfikacja. Każdy zakres, który udziela dostępu do skrzynki pocztowej użytkownika, taki jak gmail.tylko_do_odczytu, gmail.wyślij, gmail.zmodyfikujlub mail.google.com, jest wrażliwy lub ograniczony i uruchamia wymóg.
Harmonogram zależy od poziomu zakresu, którego używa Twoja aplikacja. Weryfikacja marki (zakresy niebędące poufnymi): 2-3 dni robocze. Analiza wrażliwego zakresu (gmail.wyślij, gmail.tylko_do_odczytu, gmail.zmodyfikuj): zazwyczaj 2-4 tygodnie od zakończenia zgłoszenia. CASA Poziom 2 + wrażliwe/ograniczone zakresy (mail.google.com): 4-12+ tygodni łącznie. Niekompletne zgłoszenia, takie jak brak polityki prywatności, niejasne uzasadnienia zakresu lub niedopasowane autoryzowane domeny, powodują ponowne uruchomienie zegara.
własna ocena bezpieczeństwa Google (dla poufnych zakresów, takich jak gmail.wyślij oraz gmail.tylko_do_odczytu) jest darmowy. Weryfikacja marki jest również bezpłatna. Jeśli Twoja aplikacja korzysta z ograniczonych zakresów (mail.google.com), wymagana jest audyt CASA Tier 2 przeprowadzony przez laboratorium zatwierdzone przez Google. Ścieżka samoobsługowa CASA Tier 2 na rok 2026 kosztuje około od $540 do $1 000 w opłatach laboratoryjnych. Dotychczasowa, ręcznie prowadzona ocena, wymagana dla tej samej klasy zakresu, kosztowała od $15 000 do $75 000 a ten starszy mechanizm nadal ma zastosowanie w niektórych przypadkach skrajnych i starszych aplikacjach.
Nie można pominąć weryfikacji aplikacji Google dla produkcyjnej aplikacji obsługującej zewnętrznych użytkowników z wrażliwymi zakresemami Gmail. Limit 100 użytkowników i ostrzeżenie o nieweryfikowanej aplikacji obowiązują do czasu zweryfikowania aplikacji. Zgodne alternatywy to: ustawienie aplikacji na Wewnętrzny (jeśli służy tylko użytkownikom Twojej organizacji) użyj Certyfikowany przez CASA Poziom 2 klucz OAuth Unipile podczas gdy Twoja własna weryfikacja działa równolegle, lub żądaj tylko niezarejestrowanych zakresów, które nie wywołują weryfikacji. Tworzenie wielu projektów Cloud w celu rozłożenia użytkowników pomiędzy nimi jest zabronione przez zasady Google i może skutkować zawieszeniem konta.
Widzieć Punkt końcowy interfejsu API Gmail zarządzany przez Unipile.Ostrzeżenie Gmail API „Niezweryfikowana aplikacja” pojawia się, gdy ekran zgody OAuth jest ustawiony na „Zewnętrzny”, a Twoja aplikacja żąda poufnych lub ograniczonych zakresów Gmail, ale nie zakończyła jeszcze procesu weryfikacji Google. Jest ono wyświetlane wszystkim użytkownikom spoza listy 100 użytkowników testowych. Aby je rozwiązać: prześlij swoją aplikację do Weryfikacja aplikacji Google OAuth za pośrednictwem konsoli Google Cloud lub zbudować na zweryfikowanym kluczu OAuth Unipile, certyfikowanym przez CASA Tier 2. Użytkownicy łączący się za pośrednictwem przepływu uwierzytelniania hostowanego przez Unipile nigdy nie widzą tego ostrzeżenia.
CASA Poziom 2 (Ocena Bezpieczeństwa Aplikacji w Chmurze) to niezależny audyt bezpieczeństwa wymagany przez Google dla aplikacji, które żądają ograniczonych zakresów uprawnień, głównie https://mail.google.com/, które zapewnia pełny dostęp do Gmaila na poziomie IMAP. Jest przeprowadzany przez zatwierdzone przez Google laboratorium. W 2026 roku dostępna będzie samodzielna ścieżka w przybliżeniu od $540 do $1 000. Wymagasz CASA Tier 2 tylko jeśli Twoja aplikacja żąda mail.google.com z zewnętrznych użytkowników. Jeśli używasz tylko wrażliwych zakresów (gmail.wyślij, gmail.tylko_do_odczytu, gmail.zmodyfikuj), Nie jest wymagany CASA Tier 2. Zamiast tego obowiązuje standardowa bezpłatna ocena bezpieczeństwa Google.
A Klucz API Gmail jest przeznaczony do publicznych, niezwiązanych z konkretnym użytkownikiem zapytań i nie zapewnia dostępu do żadnej skrzynki pocztowej użytkownika. Dane uwierzytelniające OAuth dla Gmail API (client_id + client_secret) służą do uzyskania autoryzacji per-użytkownika do dostępu do danych Gmail w jego imieniu. Do każdej funkcji, która odczytuje, wysyła lub modyfikuje wiadomości e-mail użytkownika, potrzebne są dane uwierzytelniające OAuth, a nie klucz API. Szczegółowe porównanie znajdziesz w naszym Klucz API Gmail vs OAuth - przewodnik.
Nadal masz pytania dotyczące weryfikacji aplikacji Google OAuth lub zarządzanego Gmail OAuth? Nasz zespół jest gotowy do pomocy.
Porozmawiaj z ekspertem
PL 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
TR