ai-max.eu · Baza wiedzy · Logowanie przez Google

Logowanie przez Google na własnej stronie. Jak to zrobić samemu? Jak z naszą aplikacją?

13 października 2026 · AI-MAX

Przycisk „Zaloguj z Google" to dziś standard: użytkownik nie wymyśla kolejnego hasła, a Ty nie przechowujesz haseł w ogóle. Brzmi prosto — i technicznie proste NIE jest. Ten poradnik piszemy dzień po wdrożeniu logowania Google we własnej aplikacji (chat.ai-max.eu), na której przeszedłesmy pełną ścieżkę błędów. Zebrały się w checklisty, które oszczędzą Ci godziny.

Zanim zaczniesz: dwa poziomy „logowania Google"

Poziom 1 — rozpoznanie użytkownika (bez backendu). Oficjalny przycisk Google Identity Services oddaje w przeglądarce tzw. ID token z adresem e-mail. Strona statyczna może go odczytać i np. wypełnić formularz zapisu. To wygodne, ale to nie jest zabezpieczenie: bez serwera, który zweryfikuje token, każdy potrafi podrobić „zalogowanego" w narzędziach deweloperskich. Do newsletterów, zapisów, prototypów.

Poziom 2 — prawdziwe konta (z backendem). Pełny przepływ OAuth „Authorization Code": użytkownik wyraża zgodę u Google, Twój serwer wymienia jednorazowy kod na token swoimi poświadczeniami, dostaje zweryfikowany e-mail i zakłada sesję w cookie. Tak działa m.in. nasza aplikacja. Wymaga serwera (PHP, Node) i sekretu aplikacji trzymanego poza plikami strony.

Nasza droga — błędy, na których się nauczyliśmy

Adres URI przekierowania musi pasować co do znaku. Ukośnik na końcu, http zamiast https, wielka litera — i Google zwraca Error 400: redirect_uri_mismatch. Podstawa: ten błąd pokazuje się dopiero po zalogowaniu użytkownika, więc na pierwszy rzut oka wszystko „wygląda na działające".
Świeżo utworzona aplikacja OAuth potrzebuje kilku minut. Godzina po rejestracji wymiana kodu potrafi zwrócić invalid_client — to nie zły sekret, tylko propagacja po stronie Google.
Ekran zgody w trybie „Testowanie" wpuszcza tylko użytkowników testowych. Inni dostają access_denied. Rozwiązanie: opublikować aplikację — dla zakresów email i openid weryfikacja Google nie jest wymagana.
Konta firmowe (Google Workspace) mają dodatkowy zamek. Polityka bezpieczeństwa organizacji blokuje aplikacje zewnętrzne: admin_policy_enforced. Jeśli to Twoja firma — odblokowujesz to sam jako administrator, w admin.google.com.
Wylogowanie zaczyna się od czystej karty. Po każdej zmianie konfiguracji test logowania robimy w nowej karcie okna prywatnego — stare strony zgody potrafią być cache'owane.

Samodzielnie, krok po kroku (poziom 2 — pełny OAuth)

Zarejestruj aplikację w Google Cloud Console (console.cloud.google.com, zakładka „Klienci"): typ Aplikacja internetowa. Jako autoryzowany identyfikator URI przekierowania wpisz dokładnie https://TwojaDomena.pl/oauth/google/powrot (pamiętaj: bez ukośnika na końcu, https, małe litery). Zapisz Client ID i Client Secret.
Skonfiguruj ekran zgody (Platforma uwierzytelniania Google): typ „Zewnętrzni", nazwa aplikacji, logo, link do polityki prywatności. Potem sekcja Odbiorcy → Publikacja → „W produkcję" — bez tego działasz tylko na liście 100 użytkowników testowych.
Przycisk na stronie kieruje na adres zgody Google z parametrami: client_id, redirect_uri (ten sam co w konsoli!), response_type=code, scope=openid email, losowy state (zabezpieczenie CSRF — zapamiętaj go w cookie).
Odbierz kod pod adresem zwrotnym: porównaj state, po czym serwer wymienia kod POST-em na oauth2.googleapis.com/token (z client_secret) i dekoduje token — adres e-mail używaj tylko, gdy Google potwierdza email_verified.
Załóż sesję: cookie HttpOnly (najlepiej z przedrostkiem __Host-), zapisz lub utwórz konto po stronie serwera. Gotowe — od tej chwili logowanie to dwa kliknięcia.

A poziom 1 bez backendu? Wklejasz skrypt accounts.google.com/gsi/client, div przycisku i funkcję odbierającą token (Google Identity Services) — Client ID jest publiczny, sekretu nie ma wcale. Pamiętaj tylko, by nie nazywać tego „bezpiecznym logowaniem": bez walidacji serwerowej to rozpoznanie demonstracyjne.

Tabela błędów — rozpoznawaj po ekranie

Co widzisz	Przyczyna	Naprawa
`Error 400: redirect_uri_mismatch`	URI w konsoli ≠ URI w żądaniu (ukośnik, http, literówka, brak)	dopisz dokładnie ten sam URI; błąd widać dopiero po zalogowaniu
`invalid_client`	zły sekret albo aplikacja młodsza niż kilka minut	sprawdź sekret; odczekaj 5 minut
`access_denied`	tryb „Testowanie", konto spoza listy testowej	opublikuj aplikację albo dodaj konto do testowych
„Skontaktuj się z administratorem organizacji Google Workspace"	polityka Workspace blokuje aplikacje zewnętrzne	admin dopuszcza aplikację: admin.google.com → Bezpieczeństwo → Aplikacje innych firm
`org_internal`	typ „Wewnętrzni" w ekranie zgody	przestaw na „Zewnętrzni" i opublikuj
`invalid_grant` przy wymianie kodu	kod starszy niż kilka minut, zużyty lub inny redirect_uri	nowa próba od zera, jeden URI wszędzie

Jak to zrobić z aplikacją AI-MAX

AI-MAX zna ten proces od podszewki — wiedza z naszego wdrożenia żyje w umiejętności agenta o nazwie „Logowanie przez Google". W praktyce:

Opisz w czacie, czego chcesz: „dodaj logowanie przez Google do tej strony". Agent zapyta o kluczową rzecz: logowanie ma chronić treść (pełny OAuth z backendem), czy wystarczy rozpoznanie użytkownika (przycisk bez backendu)?
Agent buduje od razu — łącznie ze stroną-szkieletem, która pokazuje dokładnie, czego brakuje, gdy jeszcze nie masz kluczy (nie udaje, że działa).
Rejestrację aplikacji robisz Ty — na Twoim koncie Google (to Twoja własność; agent nigdy nie prosi o hasło). Dostajesz gotową checklistę: typ aplikacji, dokładny URI przekierowania dla Twojej domeny, ekran zgody i publikacja.
Client Secret trafia do pliku środowiskowego poza plikami strony — pokazujemy dokładnie gdzie; nigdy nie ląduje w kodzie strony ani w repozytorium.

Ten sam mechanizm obsługuje logowanie przez GitHuba — wystarczy poprosić.

Zbuduj stronę z logowaniem w AI-MAX Instrukcja obsługi — krok po kroku