Ekran zgody Google OAuth: konfiguracja, poprawki i dlaczego się nie wyświetla (2026)

Przewodnik Google OAuth

Ekran zgody Google OAuth: Konfiguracja, Naprawy Gdy i dlaczego się nie pokazuje (2026)

Ekran zgody Google OAuth został przeniesiony w 2024 roku. Znajduje się teraz pod adresem Platforma uwierzytelniania Google w Cloud Console - nie tam, gdzie można było je wcześniej znaleźć. Ten przewodnik pokazuje dokładnie, gdzie się udać, jak skonfigurować je krok po kroku i jak rozwiązać najczęstsze problemy (w tym, gdy odmawia się wyświetlenia).

Co zawiera ten przewodnik
01
Gdzie to znaleźć w 2026 roku - interfejs Platformy Google Auth, który zastąpił stare menu
02
Nie wyświetla się: 5 częstych przyczyn i ich dokładne poprawki
03
Pełne, krok po kroku ustawienie Branding, Odbiorcy, Zakresy, Użytkownicy testowi
04
Wewnętrzne vs Zewnętrzne - jaki typ użytkownika wybrać i kiedy
05
Pomiń ekran zgody całkowicieSzybciej z wstępnie zweryfikowanym kluczem OAuth Unipile
Zmiana interfejsu użytkownika w 2024 r.: Google zmienił nazwę "Ekranu zgody OAuth" na "Platforma uwierzytelniania Google" z sekcjami Branding, Audience i Clients. Jeśli nie możesz znaleźć starego menu, to dlatego.
W skrócie - Szybka odpowiedź

Gdzie to jest? Od 2024 roku ekran zgody Google OAuth znajduje się pod API i Usługi > Platforma uwierzytelniania Google w Cloud Console - nie w starej pozycji menu "Ekran zgody OAuth". Ustawienia są teraz podzielone na trzy karty: Branding (nazwa aplikacji, logo, domeny), Publiczność (Typ użytkownika wewnętrzny/zewnętrzny, użytkownicy testowi), oraz Klienci (Identyfikatory klienta OAuth). Jeśli menu w ogóle się nie pojawi, Twój projekt nie włączył jeszcze żadnego interfejsu API zgodnego z OAuth, lub Twojemu kontu brakuje roli właściciela lub edytora.

Zmiana interfejsu użytkownika 2024

Gdzie jest ekran zgody OAuth w 2026 roku?

Jeśli kierowałeś się samouczkiem napisanym przed 2024 rokiem i nie możesz znaleźć "Ekranu zgody OAuth" w bocznym panelu, nie zwariowałeś. Google przemianował i zrestrukturyzował całą sekcję. Obecnie funkcjonuje pod nową nazwą: Platforma uwierzytelniania Google. Jest to najczęstszy powód, dla którego deweloperzy zgłaszają, że ekran zgody Google OAuth "nie wyświetla się" - nadal tam jest, tylko w innym miejscu.

Jak przejść do ekranu zgody w 2026 roku

Krok 1: Idź do console.cloud.google.com i upewnij się, że w selektorze projektu u góry masz wybrany właściwy projekt. Wiele problemów z brakiem wyświetlania jest spowodowanych po prostu pracą w niewłaściwym projekcie.

Krok 2: W lewym panelu bocznym kliknij API i usługi.

Krok 3: Szukaj Platforma uwierzytelniania Google w podmenu (wcześniej nazywanym "Ekran zgody OAuth"). Jeśli go widzisz, kliknij go. Jeśli nie, spójrz na poniższą sekcję rozwiązywania problemów.

Krok 4: Znajdziesz się na pulpicie nawigacyjnym platformy Google Auth. Trzy zakładki - Branding, Publicznośćoraz Klienci - zastąpić stary, jednostronicowy formularz zgody.

Starszy interfejs użytkownika (przed 2024 r.)
Ekran zgody OAuth"
Długa forma pojedyncza ze wszystkimi ustawieniami
Typ użytkownika na górze formularza
Zakresy w tej samej formie, jeden pod drugim
Test sekcji użytkowników poniżej zakresów
Nowy interfejs użytkownika - Platforma uwierzytelniania Google (2024+)
Platforma uwierzytelniania Google"
Branding / Grupa docelowa / Klienci
Typ użytkownika w zakładce Odbiorca
Zakresy skonfigurowane dla klienta OAuth w zakładce Klienci
Testowi użytkownicy również w zakładce Odbiorcy
Platforma uwierzytelniania Google - zakładka Audytorium pokazująca wybór typów użytkowników: wewnętrzni vs zewnętrzni Zakładka Audiencja na platformie Google Auth (dawniej "Ekran zgody OAuth") - tutaj wybierasz typ użytkownika Wewnętrzny lub Zewnętrzny i zarządzasz użytkownikami testowymi.
Rozwiązywanie problemów

Ekran zgody OAuth się nie wyświetla lub ciągle przekierowuje: jak to naprawić

Ekran zgody OAuth w Google może się nie wyświetlić lub działać nieprawidłowo z kilku różnych powodów. Poniżej przedstawiono poszczególne rodzaje błędów wraz z ich dokładnymi przyczynami i sposobami rozwiązania — w formie umożliwiającej jak najszybsze zapoznanie się z treścią.

Objaw
Pozycja menu "Ekran zgody OAuth" lub "Platforma uwierzytelniania Google" nie jest widoczna na pasku bocznym
Przyczyna

Interfejs Google Cloud Console zmienił się w 2024 roku. Stara pozycja menu "Ekran zgody OAuth" została zmieniona na "Platforma Google Auth". Starsze tutoriale wciąż odwołują się do starej nazwy.

Naprawić

W lewym pasku bocznym pod API i usługi, przewiń, aż zobaczysz "Platforma Google Auth". Jeśli nadal go nie widzisz, być może najpierw musisz włączyć co najmniej jedno interfejs Google API w swoim projekcie (sekcja pojawia się dopiero po włączeniu interfejsu API zgodnego z OAuth).

Objaw
Strona Google Auth Platform jest widoczna, ale pola są wyszarzone lub tylko do odczytu
Przyczyna

Twoje konto Google nie posiada Właściciel lub redaktor roli IAM w projekcie. Konta z rolą przeglądającego nie mogą edytować ustawień ekranu zgody.

Naprawić

Poproś właściciela projektu o przyznanie Ci Edytor rola (lub wyższa) przez IAM i Administrator > IAM. Jeśli sam stworzyłeś projekt, sprawdź, czy jesteś zalogowany na właściwe konto Google – selektor projektów czasami wyświetla projekty, do których masz tylko dostęp do odczytu.

Objaw
Klikasz
Przyczyna

Nie wybrałeś typ użytkownika (Wewnętrzne vs Zewnętrzne) jeszcze. W nowym interfejsie użytkownika przycisk "Rozpocznij" na stronie przeglądu Google Auth Platform wymaga najpierw ukończenia kroku Odbiorcy.

Naprawić

Na stronie przeglądu platformy uwierzytelniania Google kliknij "Rozpocznij" jeśli zostanę poproszony, przejdź do Zakładka odbiorcy i wybierz opcję „Wewnętrzny” lub „Zewnętrzny”. Po zapisaniu typu użytkownika udostępniony zostanie pełny formularz konfiguracji wizerunku marki.

Objaw
Przepływ OAuth pokazuje ekran ostrzeżenia "Ta aplikacja nie została zweryfikowana" zamiast oczekiwanego ekranu zgody
Przyczyna

Twoja aplikacja jest w Status testów (lub status publikacji to "W fazie testów") i wnioskujesz o dostęp do wrażliwych lub ograniczonych zakresów. Przed wyświetleniem właściwego ekranu zgody Google pokazuje stronę przejściową "niezweryfikowana aplikacja".

Naprawić

Do celów deweloperskich: dodaj adres e-mail użytkownika testowego do swojego lista użytkowników testowych (Zakładka Odbiorcy). W przypadku produkcji: prześlij aplikację do weryfikacji OAuth przez Google. Użytkownicy z listy użytkowników testowych nadal będą widzieć ostrzeżenie, ale mogą kontynuować klikając "Zaawansowane > Przejdź do [nazwa aplikacji]". Ostrzeżenie znika po zweryfikowaniu i opublikowaniu aplikacji.

Objaw
Ekran zgody pojawia się raz, ale nigdy więcej nie jest wyświetlany dla powracających użytkowników
Przyczyna

Jest to oczekiwane zachowanie. Gdy użytkownik udzieli zgody, Google zapamięta ją i pominie ekran przy kolejnych logowaniach. Ekran zgody pojawi się ponownie tylko wtedy, gdy użytkownik cofnie dostęp lub gdy zażądasz nowych zakresów.

Naprawić

Aby wymusić ponowne wyświetlenie w celach testowych, dodaj zgoda do parametrów adresu URL autoryzacji. W środowisku produkcyjnym używaj tylko zgoda przy pierwszym połączeniu autoryzacyjnym (aby otrzymać token_odświeżający) - nie przy.

Uwaga: jeśli Twoja aplikacja jest skonfigurowana jako Wewnętrzny (Dotyczy tylko organizacji obszaru roboczego) i testujesz z zewnętrznego konta Gmail, ekran zgody nigdy się nie pojawi – otrzymasz odmowa_dostępu zamiast tego wystąpił błąd. Aplikacje wewnętrzne są z założenia ograniczone do użytkowników w Twojej organizacji Google Workspace. Przełącz się na zewnętrzne, jeśli potrzebujesz obsługiwać użytkowników spoza Workspace.
Chcesz pominąć te poprawki?

Weryfikowalny klucz OAuth firmy Unipile eliminuje te scenariusze błędów w Twojej konfiguracji – brak konfiguracji ekranu zgody po Twojej stronie, jako niezależny pośrednik techniczny działający w imieniu każdego uwierzytelnionego użytkownika.

Pomiń te poprawki
Konfiguracja krok po kroku

Jak krok po kroku skonfigurować ekran zgody OAuth

Sekcja ta obejmuje pełną konfigurację ekranu zgody – część, którą należy wykonać po utworzeniu projektu Google Cloud i włączeniu interfejsu API Google. Jeśli nie wykonałeś tych kroków, zobacz Pełny przewodnik po Google OAuth która najpierw obejmuje tworzenie projektu i aktywację API.

Wymagania wstępne Masz projekt Google Cloud z co najmniej jednym włączonym interfejsem API (np. Gmail API, Calendar API). Masz rolę właściciela lub edytora IAM w projekcie. Przejdź do API i Usługi > Platforma uwierzytelniania Google na początek.
A
Wybierz swój typ użytkownika: Wewnętrzny vs Zewnętrzny

W Zakładka odbiorcy, - pierwsza decyzja dotyczy tego, czy Twoja aplikacja obsługuje użytkowników wewnątrz Twojej organizacji Google Workspace, czy też każdego użytkownika z kontem Google

  • Wewnętrzne: tylko użytkownicy w Twojej organizacji Google Workspace. Nie jest wymagane żadne uwierzytelnianie. Idealne dla narzędzi wewnętrznych, paneli administracyjnych lub aplikacji korporacyjnych używanych tylko przez Twoich własnych pracowników. Niedostępne, jeśli projekt jest powiązany z osobistym kontem Gmail (tylko konta Workspace).
  • Zewnętrzny każdy posiadacz konta Google. Aplikacje uruchamiane są w trybie "Testowanie" z limitem 100 użytkowników. Obszary wrażliwe lub ograniczone wymagają procesu weryfikacji przez Google, zanim aplikacja będzie mogła zostać opublikowana dla wszystkich użytkowników.
Google Auth Platform Karta Odbiorcy - wybór typu użytkownika Wewnętrzny lub Zewnętrzny dla ekranu zgody OAuth Zakładka Odbiorcy: wybierz Wewnętrzni (tylko w Workspace) lub Zewnętrzni (dowolne konto Google). Ta decyzja wpływa na Twoje wymagania dotyczące weryfikacji.

Wskazówka: Możesz zmienić z wewnętrznego na zewnętrzne później, ale nie możesz zmienić z zewnętrznego z powrotem na wewnętrzne po autoryzacji aplikacji przez użytkowników. Wybieraj ostrożnie.

W Zakładka marki, wypełnij następujące pola. Są to pola widoczne dla użytkowników na ekranie zgody Google OAuth podczas autoryzacji aplikacji:

  • Nazwa aplikacji: nazwa wyświetlana wyraźnie na górze ekranu zgody. Użyj nazwy swojego produktu, a nie identyfikatora technicznego.
  • E-mail do pomocy technicznej: wyświetlany na ekranie zgody jako kontakt dla użytkowników, którzy mają pytania dotyczące żądania dostępu przez Twoją aplikację. Użyj monitorowanego aliasu lub listy dystrybucyjnej – nie prywatnego adresu e-mail.
  • Logo aplikacji: kwadratowy plik PNG lub JPG, minimum 120x120 pikseli. Wyświetla się na ekranie zgody i na liście autoryzowanych aplikacji w Koncie Google. Opcjonalne, ale zdecydowanie zalecane dla budowania zaufania użytkowników.
Zakładka Branding platformy Google Auth - Pola informacji o aplikacji: nazwa, logo, adres e-mail wsparcia Zakładka Branding - Informacje o aplikacji: wprowadź nazwę aplikacji, logo i adres e-mail pomocy technicznej dokładnie tak, jak chcesz, aby były wyświetlane użytkownikom na ekranie zgody.

Nadal w Zakładka marki, sekcja Domeny aplikacji wymaga następujących linków:

  • Adres URL strony głównej aplikacji: publiczna strona główna Twojej aplikacji lub produktu. Musi być aktywnym, dostępnym adresem URL (nie strona logowania).
  • Polityka Prywatności link: wymagana dla wszystkich aplikacji zewnętrznych żądających zakresów poza podstawowym logowaniem. Należy wyraźnie wymienić żądane zakresy Google oraz sposób wykorzystania danych. Zespół weryfikacyjny Google dokładnie to sprawdza – brak lub niejasna polityka prywatności jest najczęstszą przyczyną odrzucenia.
  • Link do Warunków korzystania z usługi: opcjonalne, ale zalecane dla aplikacji produkcyjnych.
Platforma Google Auth - sekcja domen aplikacji: strona główna, polityka prywatności, adresy URL warunków korzystania z usługi Domena aplikacji: podaj aktywne adresy URL swojej strony głównej, polityki prywatności i warunków korzystania z usługi. Wszystkie adresy URL muszą być public.

The Autoryzowane domeny sekcja (poniżej App Domain) kontroluje, które domeny mogą być używane w Twoich URI przekierowania OAuth oraz w linkach domen aplikacji powyżej. Dodaj domenę główną swojej aplikacji (np. yourapp.com).

Platforma uwierzytelniania Google, zakładka Branding – konfiguracja autoryzowanych domen Autoryzowane Domeny: dodaj swoją domenę główną. Google zaakceptuje tylko adresy URI przekierowania i adresy URL aplikacji z tej domeny.

Wskazówka: autoryzowane domeny i identyfikatory URI przekierowania (ustawione w zakładce Klienci) muszą być spójne. Jeśli Twój identyfikator URI przekierowania jest https://app.yourapp.com/callback, musisz autoryzować yourapp.com tutaj, nie app.yourapp.com.

Również w Zakładka marki, podaj adres e-mail do kontaktu z deweloperem. Jest to adres, który Google wykorzystuje do wysyłania:

  • Aktualizacje statusu weryfikacji (zatwierdzenie, odrzucenie lub prośba o wyjaśnienie)
  • Zawiadomienia o zgodności z polityką
  • Powiadomienia o zmianach w statusie OAuth aplikacji
Platforma Google Auth - Pola informacji kontaktowych dewelopera Kontakt dla deweloperów: użyj monitorowanej listy dystrybucyjnej. Krytyczne e-maile weryfikacyjne Google mogą zostać oznaczone jako spam – sprawdzaj folder spam podczas okna przeglądu.

Ważne: skorzystaj z listy dystrybucyjnej lub współdzielonej skrzynki pocztowej, a nie z prywatnego adresu e-mail. Zespół weryfikacyjny Google może wysyłać wiadomości e-mail w godzinach pracy w innej strefie czasowej. Jeśli przegapisz okno odpowiedzi, weryfikacja może zostać opóźniona o tygodnie.

Zakresy definiują dane, do których Twoja aplikacja może uzyskać dostęp w imieniu użytkownika. W nowym interfejsie Google Auth Platform zakresy można skonfigurować dla każdego klienta OAuth (w sekcji Zakładka Klienci > wybierz klienta > Zakresy). Kliknij "Dodaj lub usuń zakresy" aby otworzyć selektor zakresu.

Kategorie zakresu, które mają wpływ na ścieżkę weryfikacji:

  • Zakresy niejawne (na przykład. openid, e-mail, profil): podstawowe logowanie. Nie wymaga weryfikacji. Aplikacja publikowana natychmiast.
  • Czułe zakresy (na przykład. gmail.tylko_do_odczytu, gmail.wyślij, etykiety gmail): Wymagane jest przejście oceny bezpieczeństwa Google (weryfikacja OAuth). Aplikacja pozostaje w trybie testowym do czasu weryfikacji.
  • Ograniczone zakresy (na przykład. mail.google.com, gmail.zmodyfikuj): wymaga zarówno weryfikacji Google OAuth, JAK I audytu bezpieczeństwa CASA Tier 2. Znacznie dłużej trwa.
Panel "Dodaj lub usuń zakresy" w Google Auth Platform pokazujący dostępne uprawnienia interfejsu Gmail API Selektor zakresów uprawnień: wybierz minimalne zakresy uprawnień, których Twoja aplikacja faktycznie potrzebuje. Każdy wrażliwy lub ograniczony zakres uprawnień dodaje wymogi weryfikacji. Zaplanuj to przed rozpoczęciem budowy.

Aby uzyskać pełne odniesienie do zakresów specyficznych dla Gmaila, które interfejsy API każdy z nich odblokowuje oraz jak je zażądać w adresie URL autoryzacji, zobacz Przewodnik po zakresach Gmail API.

Zasada najmniejszych uprawnień Występuj tylko o zakresy, których Twoja aplikacja aktualnie używa. Dodanie ograniczonego zakresu po uruchomieniu oznacza ponowne rozpoczęcie całego procesu weryfikacji, w tym nowego audytu CASA Tier 2.

W Zakładka odbiorcy, the Testowi użytkownicy sekcja pozwala na dodanie adresów e-mail konta Google, które mogą autoryzować Twoją aplikację, gdy jest ona w Status testów.

Kluczowe zasady dotyczące limitu użytkowników testowych:

  • Maksymalnie 100 użytkowników testowych Można dodać do aplikacji zewnętrznej w stanie testowania. Jest to sztywne ograniczenie Google – nie można go zwiększyć bez publikacji aplikacji.
  • Użytkownicy testowi widzą ekran ostrzeżenia "niezweryfikowana aplikacja", ale nadal mogą autoryzować Twoją aplikację, klikając w ostrzeżenie.
  • Tokeny dostępu dla użytkowników testowych w trybie testowym wygasają po 7 dni. Użytkownicy muszą ponownie autoryzować się, gdy token wygaśnie.
  • Po złożeniu wniosku o weryfikację i zatwierdzeniu aplikacji przez Google, limit 100 użytkowników zostaje zniesiony, a 7-dniowy termin wygaśnięcia znika.

Jeśli potrzebujesz więcej niż 100 użytkowników przed weryfikacją: Jedyną opcją jest przesłanie aplikacji do weryfikacji przez Google. Nie ma obejścia w systemach Google. Alternatywnie, rozważ, czy wstępnie zweryfikowany.

Chcesz pominąć cały proces konfiguracji ekranu zgody OAuth?

Użyj zweryfikowanego klucza OAuth z Unipile zamiast tego - bez ekranu zgody, bez limitu 100 użytkowników, bez oczekiwania na weryfikację.

Użyj klucza Unipile
Decyzja typu użytkownika

Wewnętrzne czy zewnętrzne: które wybrać?

Wybór między "wewnętrzny" a "zewnętrzny" na ekranie zgody Google OAuth jest jedną z najbardziej znaczących decyzji w konfiguracji. Określa on ścieżkę weryfikacji, bazę użytkowników i to, czy podczas rozwoju będziesz musiał zmierzyć się z limitem 100 użytkowników. Oto pełny obraz.

Wewnętrzny
Organizacja przestrzeni roboczej
Nie jest wymagana weryfikacja - nigdy
Brak limitu użytkowników testowych
Ekran ostrzegawczy "niezweryfikowana aplikacja" nie istnieje
Wymagane konto Google Workspace (nie prywatny Gmail)
Nie można obsługiwać klientów zewnętrznych
Najlepsze dla: Narzędzia wewnętrzne firmy, panele administracyjne, narzędzia deweloperskie, aplikacje HR, dowolna aplikacja, w której wszyscy użytkownicy należą do Twojej organizacji Workspace.
Zewnętrzny
Dowolne konto Google
Każde konto Google może autoryzować Twoją aplikację
Działa z osobistymi kontami Gmail i Workspace
limit 100 użytkowników w trybie testowym
Zakresy wrażliwe/ograniczone wymagają weryfikacji przez Google
Użytkownicy widzą ostrzeżenie "niezweryfikowana aplikacja" do czasu weryfikacji.
Najlepsze dla: Produkty SaaS, aplikacje konsumenckie, narzędzia deweloperskie przeznaczone dla każdego klienta z kontem Google.
Przewodnik do szybkiego podejmowania decyzji
Czy jacyś użytkownicy będą spoza Twojej organizacji Google Workspace?
Tak - wybierz Zewnętrzny
Czy Twój projekt jest powiązany z osobistym kontem Gmail (nie Workspace)?
Musi używać zewnętrznego
Tworzysz narzędzie wewnętrzne, w którym wszyscy użytkownicy należą do organizacji Workspace Twojej firmy?
Użyj wewnętrzne
Chcesz całkowicie ominąć weryfikację Google i nadal obsługiwać użytkowników zewnętrznych?
Zobacz sekcję "Pomiń" poniżej

Pomiń całkowicie decyzję o wewnętrznym kontra zewnętrznym

Dzięki wstępnie zweryfikowanemu kluczowi OAuth Unipile możesz obsługiwać użytkowników zewnętrznych bez weryfikacji przez Google - Unipile działa jako niezależny pośrednik techniczny w imieniu każdego uwierzytelnionego użytkownika.

Pomiń konfigurację
Po konfiguracji

Po ekranie zgody: weryfikacja i CASA

Konfiguracja ekranu zgody Google OAuth nie jest końcem procesu dla aplikacji zewnętrznych żądających poufnych lub ograniczonych zakresów. Dalsze kroki zależą od tego, jakie zakresy wybrałeś. Oto krótka wersja - pełne weryfikacja i instrukcja CASA znajduje się w centrum Google OAuth.

1
Aplikacja jest w trybie testowym (limit 100 użytkowników)

Zaraz po skonfigurowaniu ekranu zgody OAuth, twoja zewnętrzna aplikacja znajduje się w Status testów. Tylko użytkownicy dodani do listy użytkowników testowych (do 100) mogą autoryzować Twoją aplikację. Jest to w porządku w przypadku opracowywania i wczesnych testów.

2
Prześlij do weryfikacji Google OAuth

Kiedy będziesz gotów udostępnić swoją aplikację większej liczbie użytkowników, kliknij "Przygotuj się do weryfikacji" (lub "Prześlij do weryfikacji") w przeglądzie Google Auth Platform. Google sprawdza politykę prywatności Twojej aplikacji, autoryzowane domeny, żądane zakresy i sposób, w jaki aplikacja wykorzystuje dane. Czas weryfikacji jest różny – zazwyczaj wynosi 2–6 tygodni, czasem dłużej w przypadku restrykcyjnych zakresów.

3
Audyt CASA Tier 2 (tylko ograniczone zakresy)

Jeśli Twoja aplikacja żąda ograniczonych zakresów (takich jak mail.google.com lub gmail.zmodyfikuj), Google dodatkowo wymaga Audyt bezpieczeństwa CASA Tier 2 przez zatwierdzonego zewnętrznego asesora. Obejmuje to analizę stanu bezpieczeństwa aplikacji, obsługi danych i kontroli dostępu.

4
Aplikacja opublikowana - brak dalszych ostrzeżeń

Po weryfikacji aplikacja zostaje opublikowana. Znika ekran ostrzeżenia o "nieweryfikowalnej aplikacji". Zostaje zniesiony limit 100 użytkowników. 7-dniowy termin wygaśnięcia tokenów dla użytkowników testowych przestaje obowiązywać. Użytkownicy widzą ekran zgody z Twoją marką bez ostrzeżeń.

Aby uzyskać szerszy obraz tego, jak Google OAuth pasuje do architektury API poczty e-mail – w tym zunifikowany dostęp do dostawców w Gmailu, Outlooku i IMAP – zobacz Przewodnik po API poczty elektronicznej.

Unipile posiada certyfikat CASA Tier 2

Firma Unipile zakończyła już audyt CASA Tier 2 dotyczący integracji z Google OAuth. Oznacza to, że gdy korzystasz z Unipile jako niezależny pośrednik techniczny, działając w imieniu każdego uwierzytelnionego użytkownika, nie musisz przechodzić przez proces CASA samodzielnie. Zobacz centrum Google OAuth szczegóły dotyczące ścieżki certyfikacji Unipile oraz sposobu działania przepływu pracy POC / certyfikuj później / przełącz.

Szybsza Ścieżka

Pomiń całkowicie konfigurację ekranu zgody

Jeśli Twój produkt musi uzyskać dostęp do danych Gmail lub Google Calendar użytkowników, możesz wybrać samodzielne skonfigurowanie ekranu zgody Google OAuth lub możesz użyć Unipile jako niezależny pośrednik techniczny, działając w imieniu każdego uwierzytelnionego użytkownika, z pre-zweryfikowanym kluczem OAuth, który już posiada certyfikat CASA Tier 2. To nie jest obejście procesu weryfikacji bezpieczeństwa Google. Unipile przeprowadził dla Ciebie ten przegląd – to jest produkt.

Unipile nie jest powiązany z firmą Google, nie jest przez nią wspierany ani sponsorowany. Unipile działa jako niezależny pośrednik techniczny między Twoją aplikacją.

Skonfiguruj to sam
Skonfiguruj swój własny ekran zgody OAuth
Skonfiguruj zakładki Branding, Audience, Clients w Platformie Google Auth
100 użytkowników - limit podczas fazy testów
Weryfikacja Google OAuth (2-6 tygodni)
Audyt CASA Tier 2 (dla ograniczonych zakresów)
Użytkownicy widzą ostrzeżenie "niezweryfikowana aplikacja" do czasu weryfikacji.
Użyj klucza Unipile
Wstępnie zweryfikowana integracja OAuth Unipile
Brak konfiguracji ekranu zgody z Twojej strony
Bez limitu 100
Weryfikacja Google została już wykonana
Certyfikacja CASA Tier 2 zakończona
Brak ostrzeżenia o "niezweryfikowanej aplikacji" dla Twoich użytkowników
Zacznij budować. Nie jest potrzebny ekran zgody.

Połącz konta Google swoich użytkowników za pomocą zweryfikowanej integracji OAuth firmy Unipile. Twoi użytkownicy autoryzują raz – Unipile zajmuje się resztą, jako niezależny pośrednik techniczny, w imieniu każdego uwierzytelnionego użytkownika.

To nie jest obejście procesu weryfikacji bezpieczeństwa Google. Unipile zakończyło proces weryfikacji OAuth firmy Google oraz audyt CASA Tier 2 w ramach swojej oferty produktowej. Twoja aplikacja łączy się z interfejsami API Google za pośrednictwem Unipile jako zweryfikowanego, niezależnego pośrednika technicznego. Unipile nie jest powiązany z Google, nie jest przez nią wspierany ani sponsorowany. Decyzje po stronie klienta dotyczące wykorzystania danych i zgody użytkownika pozostają odpowiedzialnością Twojej aplikacji.

Ekran zgody Google OAuth - Często zadawane pytania

Najczęstsze pytania dotyczące konfiguracji, rozwiązywania problemów i nawigacji po ekranie zgody Google OAuth w 2026 roku.

Istnieje pięć częstych powodów: (1) Szukasz starego menu "Ekran zgody OAuth" – zostało ono przemianowane na "Platforma Google Auth" w 2024 roku. (2) Jesteś w złym projekcie – sprawdź selektor projektu na górze. (3) Twoje konto nie ma roli właściciela ani redaktora IAM. (4) W projekcie nie włączono jeszcze żadnego interfejsu API zgodnego z OAuth – sekcja Platforma Google Auth pojawia się dopiero po aktywacji interfejsu API. (5) Twoja aplikacja jest skonfigurowana jako wewnętrzna, ale testujesz ją za pomocą zewnętrznego konta Google – aplikacje wewnętrzne domyślnie blokują wszystkich użytkowników spoza Workspace. Szczegółowe rozwiązania znajdziesz w sekcji sekcja rozwiązywania problemów powyżej.

Od 2024 roku przejdź do API i Usługi > Platforma uwierzytelniania Google. Element menu "Ekran zgody OAuth" został zastąpiony przez „Platformę uwierzytelniania Google”, która organizuje ustawienia w trzech kartach: Branding (nazwa aplikacji, logo, domeny), Publiczność (Typ użytkownika wewnętrzny/zewnętrzny, użytkownicy testowi), oraz Klienci (Identyfikatory klientów OAuth i identyfikatory URI przekierowania). Ta reorganizacja interfejsu użytkownika jest główną przyczyną wyszukiwania "nie pojawia się ekran zgody google oauth" w 2026 roku.

Więcej o tym w naszym Kompletny przewodnik po Google OAuth Playground.

Wewnętrznywszyscy użytkownicy znajdują się w Twojej organizacji Google Workspace, weryfikacja nigdy nie jest wymagana, limit użytkowników testowych nie obowiązuje, ostrzeżenie o niezweryfikowanym koncie nie jest wyświetlane. Najlepsze dla narzędzi wewnętrznych. Wymaga konta Workspace (nie osobistego Gmail).

ZewnętrznyKażdy posiadacz konta Google może korzystać z Twojej aplikacji. Rozpoczyna działanie w trybie testowym (ograniczenie do 100 użytkowników). Wrażliwe zakresy wymagają weryfikacji Google (2-6 tygodni). Ograniczone zakresy dodatkowo wymagają CASA Tier 2. Wybierz Zewnętrzny dla każdej aplikacji publicznej lub skierowanej do klientów.

Twardy limit to 100 testerów dla aplikacji zewnętrznych w stanie testowania. Ten limit jest ustawiony przez Google i nie można go ominąć. Użytkownicy testowi nadal mogą autoryzować Twoją aplikację, ale najpierw zobaczą ekran ostrzeżenia. Ich tokeny wygasają po 7 dni (zamiast normalnego czasu życia tokenu odświeżania). Aby znieść limit, prześlij swoją aplikację do weryfikacji OAuth Google. Po publikacji nie ma limitu użytkowników.

To zależy od Twojej konfiguracji: Aplikacje wewnętrzne nigdy nie wymaga weryfikacji. Aplikacje zewnętrzne używające tylko podstawowych zakresów (openid, e-mail, profil) może publikować bez weryfikacji. Aplikacje zewnętrzne żądające wrażliwych zakresów jak gmail.wyślij, gmail.tylko_do_odczytu) musi przejść weryfikację OAuth Google przed zniesieniem limitu 100 użytkowników. Aplikacje zewnętrzne żądające ograniczonych zakresów jak mail.google.com) dodatkowo wymagają audytu bezpieczeństwa CASA Tier 2 – oprócz standardowej weryfikacji. Zobacz Przewodnik po zakresach Gmail API dla pełnego zakresu klasyfikacji.

Nie można pominąć ekranu zgody Google OAuth w obrębie własnej infrastruktury Google – jest to wymagany krok w każdym przepływie OAuth 2.0. Można jednak uniknąć samodzielnego konfigurowania i weryfikowania go, korzystając z Klucz OAuth zweryfikowany przez Unipile. Unipile działa jako niezależny pośrednik techniczny, w imieniu każdego uwierzytelnionego użytkownika, z zakończoną weryfikacją Google i certyfikatem CASA Tier 2. To nie jest obejście zabezpieczeń - Unipile przeszedł pełny proces weryfikacji Google. Twoi użytkownicy nadal widzą ekran zgody (zweryfikowany przez Unipile), po prostu nie musisz budować i weryfikować własnego.

Odkryj produkcyjna integracja z Gmail API.

Nadal masz pytania dotyczące konfiguracji Google OAuth? Nasz zespół jest tutaj, aby pomóc.

Porozmawiaj z ekspertem
pl_PLPL