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).
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.
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.
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.
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.
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ą.
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.
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).
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.
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.
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.
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.
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".
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.
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.
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.
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.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.
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.
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.
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 - 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.
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).
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
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.
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ę.
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.
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.
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.
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.
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.
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.
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.
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.
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ą.
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.
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.