Łączenie konta Google z OAuth

Konta są łączone za pomocą standardowych przepływów OAuth 2.0: pośredniego i kodu autoryzacji.

Usługa musi obsługiwać zgodne z OAuth 2.0 punkty końcowe autoryzacji i wymiany tokenów.

W procesie domyślnym Google otwiera Twój punkt końcowy autoryzacji w przeglądarce użytkownika. Po zalogowaniu się zwracasz do Google długotrwały token dostępu. Ten token dostępu jest teraz dołączany do każdego żądania wysyłanego z Google.

W przepływie kodu autoryzacji musisz użyć 2 punktów końcowych:

Punkt końcowy autoryzacji, który wyświetla interfejs logowania użytkownikom, którzy nie są jeszcze zalogowani. Punkt końcowy autoryzacji tworzy też krótkotrwały kod autoryzacji, aby zarejestrować zgodę użytkownika na żądany dostęp.
Punkt końcowy wymiany tokenów, który odpowiada za 2 rodzaje wymiany:
1. Wymienia kod autoryzacji na długotrwały token odświeżania i token dostępu o ograniczonym czasie ważności. Wymiana ta następuje, gdy użytkownik przechodzi przez proces łączenia kont.
2. Wymiana długoterminowego tokena odświeżania na krótkoterminowy token dostępu. Wymiana ta ma miejsce, gdy Google potrzebuje nowego tokena dostępu, ponieważ poprzedni wygasł.

Wybierz przepływ OAuth 2.0

Chociaż przepływ domyślnie jest prostszy do wdrożenia, Google zaleca, aby tokeny dostępu wydane w ramach procesu niejawnego nigdy nie wygasały. Dzieje się tak, ponieważ użytkownik musi ponownie połączyć swoje konto po wygaśnięciu tokena w ramach procesu niejawnego. Jeśli ze względów bezpieczeństwa potrzebujesz tokenu z terminem ważności, zdecydowanie zalecamy użycie przepływu kodu autoryzacji.

Wskazówki dotyczące wyglądu

W tej sekcji znajdziesz wymagania dotyczące projektu i zalecenia dotyczące ekranu użytkownika, który hostujesz w ramach procesów łączenia OAuth. Gdy wywoła go aplikacja Google, Twoja platforma wyświetli użytkownikowi stronę logowania do Google i ekran z prośbą o zgodę na połączenie kont. Po wyrażeniu zgody na połączenie kont użytkownik zostaje przekierowany z powrotem do aplikacji Google.

Ilustracja pokazująca, jak użytkownik może połączyć swoje konto Google z Twoim systemem uwierzytelniania Pierwszy zrzut ekranu przedstawia linki inicjowane przez użytkownika na Twojej platformie. Drugi obraz przedstawia logowanie użytkownika w Google, a trzeci – zgodę użytkownika i potwierdzenie połączenia konta Google z Twoją aplikacją. Ostatni zrzut ekranu przedstawia konto użytkownika w aplikacji Google. — **Rysunek 1.** Ekrany logowania użytkownika do Google i ekrany zgody.

Wymagania

Musisz poinformować, że konto użytkownika zostanie połączone z Google, a nie z konkretną usługą Google, taką jak Google Home czy Asystent Google.

Rekomendacje

Zalecamy wykonanie tych czynności:

Wyświetlanie Polityki prywatności Google Dodaj link do Polityki prywatności Google na ekranie zgody.
Dane do udostępnienia. Używaj jasnego i zwięzłego języka, aby poinformować użytkownika, jakich danych wymaga Google i dlaczego.
Wyraźne wezwanie do działania. Na ekranie z prośbą o zgodę umieść wyraźne wezwanie do działania, np. „Zgadzam się i chcę połączyć”. Użytkownicy muszą wiedzieć, jakie dane muszą udostępnić Google, aby połączyć swoje konta.
Możliwość anulowania. zapewnienie użytkownikom możliwości powrotu do poprzedniego ekranu lub anulowania połączenia, jeśli nie chcą go nawiązać;
Jednoznaczny proces logowania. Zadbaj o to, aby użytkownicy mieli jasną metodę logowania się na konto Google, np. pola na nazwę użytkownika i hasło lub przycisk Zaloguj się przez Google.
Możliwość odłączenia. Udostępnij użytkownikom mechanizm umożliwiający odłączenie konta, np. adres URL do ustawień konta na Twojej platformie. Możesz też dołączyć link do konta Google, na którym użytkownicy mogą zarządzać połączonym kontem.
Możliwość zmiany konta użytkownika. Zaproponuj użytkownikom sposób przełączania kont. Jest to szczególnie korzystne, jeśli użytkownicy mają tendencję do tworzenia wielu kont.
- Jeśli użytkownik musi zamknąć ekran akceptacji, aby przełączyć się na inne konto, prześlij do Google nieodwracalny błąd, aby użytkownik mógł zalogować się na odpowiednie konto za pomocą linkowania OAuth i przepływu utajonego.
Dołącz logo. Wyświetlać logo firmy na ekranie zgody. Umieść logo na podstawie wytycznych dotyczących stylu. Jeśli chcesz wyświetlać też logo Google, zapoznaj się z artykułem Logotypy i znaki towarowe.

Tworzenie projektu

Aby utworzyć projekt do łączenia kont:

Otwórz konsolę interfejsów API Google.
Kliknij Utwórz projekt.
Wpisz nazwę lub zaakceptuj wygenerowaną sugestię.
Potwierdź lub edytuj pozostałe pola.
Kliknij Utwórz.

Aby wyświetlić identyfikator projektu:

Otwórz konsolę interfejsów API Google.
Znajdź swój projekt w tabeli na stronie docelowej. Identyfikator projektu jest wyświetlany w kolumnie Identyfikator.

Konfigurowanie ekranu zgody OAuth

Proces łączenia z kontem Google obejmuje ekran zgody, na którym użytkownicy mogą zobaczyć, która aplikacja prosi o dostęp do ich danych, jakich danych żąda i jakie warunki mają zastosowanie. Zanim wygenerujesz identyfikator klienta interfejsu API Google, musisz skonfigurować ekran zgody OAuth.

Otwórz stronę ekranu zgody OAuth w konsoli interfejsów API Google.
Jeśli pojawi się prośba, wybierz projekt, który właśnie utworzyłeś.
Na stronie „Ekran zgody OAuth” wypełnij formularz i kliknij przycisk „Zapisz”.

Nazwa aplikacji: nazwa aplikacji, która prosi o akceptację. Nazwa powinna dokładnie odzwierciedlać Twoją aplikację i być zgodna z nazwą aplikacji, którą użytkownicy widzą w innych miejscach. Nazwa aplikacji będzie wyświetlana na ekranie zgody na łączenie kont.

Logo aplikacji: obraz na ekranie zgody, który pomoże użytkownikom rozpoznać Twoją aplikację. Logo jest wyświetlane na ekranie zgody na łączenie kont i w ustawieniach konta.

Adres e-mail pomocy: dla użytkowników, którzy chcą się z Tobą skontaktować w sprawie pytań o ich zgodę.

Zakresy interfejsów API Google: zakresy umożliwiają aplikacji dostęp do prywatnych danych Google użytkownika. W przypadku łączenia z kontem Google wystarczy domyślny zakres (e-mail, profil, OpenID). Nie musisz dodawać żadnych zakresów wrażliwych. Zasadniczo najlepszym rozwiązaniem jest żądanie zakresów przyrostowo, w momencie, gdy wymagany jest dostęp, a nie z góry. Więcej informacji.

Autoryzowane domeny: aby chronić Ciebie i Twoich użytkowników, Google pozwala na używanie autoryzowanych domen tylko aplikacjom, które uwierzytelniają się za pomocą protokołu OAuth. Linki do Twoich aplikacji muszą być hostowane w autoryzowanych domenach. Więcej informacji.

Link do strony głównej aplikacji: strona główna Twojej aplikacji. Musi być hostowana w autoryzowanej domenie.

Link do polityki prywatności aplikacji: Wyświetlany na ekranie zgody na łączenie kont Google. Musi być hostowana w autoryzowanej domenie.

Link do Warunków korzystania z usługi (opcjonalnie): musi być hostowany w autoryzowanej domenie.

Rysunek 1. Ekran zgody na łączenie z kontem Google w przypadku fikcyjnej aplikacji Tunery
Sprawdź „Stan weryfikacji”. Jeśli Twoja aplikacja wymaga weryfikacji, kliknij przycisk „Prześlij do weryfikacji”, aby przesłać aplikację do weryfikacji. Szczegółowe informacje znajdziesz w wymaganiach dotyczących weryfikacji OAuth.

Wdrażanie serwera OAuth

Implementacja serwera OAuth 2.0 w przypadku przepływu kodu autoryzacji składa się z 2 punktów końcowych, które usługa udostępnia przez HTTPS. Pierwszy punkt końcowy to punkt końcowy autoryzacji, który odpowiada za znajdowanie lub uzyskiwanie zgody użytkowników na dostęp do danych. Punkt autoryzacji wyświetla interfejs logowania użytkownikom, którzy nie są jeszcze zalogowani, i rejestruje zgodę na żądany dostęp. Drugi punkt końcowy to punkt końcowy wymiany tokenów, który służy do uzyskiwania zaszyfrowanych ciągów znaków, zwanych tokenami, które autoryzują użytkownika do uzyskiwania dostępu do Twojej usługi.

Gdy aplikacja Google musi wywołać jeden z interfejsów API Twojej usługi, Google używa tych punktów końcowych, aby uzyskać od użytkowników pozwolenie na wywoływanie tych interfejsów API w ich imieniu.

Łączenie z kontem Google: przepływ kodu autoryzacji protokołu OAuth

Poniższy diagram sekwencji przedstawia interakcje między użytkownikiem, Google i punktami końcowymi Twojej usługi.

Rysunek 1. Sekwencja zdarzeń w przepływie kodu autoryzacji OAuth 2.0 na potrzeby łączenia z kontem Google.

Role i obowiązki

W tabeli poniżej znajdziesz role i obowiązki podmiotów w przepływie protokołu OAuth łączenia z kontem Google (GAL). Pamiętaj, że w GAL Google pełni rolę klienta OAuth, a Twoja usługa – dostawcy tożsamości lub usługi.

Użytkownik, który wykonał czynność lub komponent	Rola GAL	Podmiot odpowiedzialny
Aplikacja / serwer Google	Klient OAuth	Inicjuje proces, odbiera kod autoryzacji, wymienia go na tokeny i bezpiecznie je przechowuje, aby uzyskać dostęp do interfejsów API usługi.
Punkt końcowy autoryzacji	Serwer autoryzacji	Uwierzytelnia użytkowników i uzyskuje ich zgodę na udostępnianie Google dostępu do ich danych.
Punkt końcowy wymiany tokenów	Serwer autoryzacji	Weryfikuje kody autoryzacji i tokeny odświeżania oraz wydaje tokeny dostępu serwerowi Google.
Identyfikator URI przekierowania Google	Punkt końcowy wywołania zwrotnego	Otrzymuje przekierowanie użytkownika z usługi autoryzacji z wartościami `code` i `state`.

Sesja przepływu kodu autoryzacji OAuth 2.0 zainicjowana przez Google przebiega w ten sposób:

Google otwiera punkt końcowy autoryzacji w przeglądarce użytkownika. Jeśli przepływ został rozpoczęty na urządzeniu obsługującym tylko głos w przypadku działania, Google przenosi wykonanie na telefon.
Użytkownik loguje się (jeśli nie jest jeszcze zalogowany) i przyznaje Google uprawnienia dostępu do swoich danych za pomocą Twojego interfejsu API (jeśli nie zrobił tego wcześniej).
Usługa tworzy kod autoryzacji i zwraca go do Google. Aby to zrobić, przekieruj przeglądarkę użytkownika z powrotem do Google z kodem autoryzacji dołączonym do żądania.
Google wysyła kod autoryzacji do punktu końcowego wymiany tokenów, który weryfikuje autentyczność kodu i zwraca token dostępu oraz token odświeżania. Token dostępu to krótkoterminowy token, który Twoja usługa akceptuje jako dane logowania umożliwiające dostęp do interfejsów API. Token odświeżania to token o długim okresie ważności, który Google może przechowywać i używać do uzyskiwania nowych tokenów dostępu po wygaśnięciu poprzednich.
Po zakończeniu procesu łączenia kont przez użytkownika każde kolejne żądanie wysyłane z Google zawiera token dostępu.

Obsługa próśb o autoryzację

Gdy musisz przeprowadzić łączenie kont za pomocą przepływu kodu autoryzacji OAuth 2.0, Google wysyła użytkownika do Twojego punktu końcowego autoryzacji z żądaniem zawierającym te parametry:

Parametry punktu końcowego autoryzacji
`client_id`	Identyfikator klienta przypisany przez Ciebie do Google.
`redirect_uri`	Adres URL, na który wysyłasz odpowiedź na to żądanie.
`state`	Wartość księgowa, która jest przekazywana z powrotem do Google bez zmian w identyfikatorze URI przekierowania.
`scope`	Opcjonalnie: zestaw ciągów zakresu oddzielonych spacjami, które określają dane, do których Google prosi o autoryzację.
`response_type`	Typ wartości, która ma zostać zwrócona w odpowiedzi. W przypadku przepływu kodu autoryzacji OAuth 2.0 typ odpowiedzi jest zawsze `code`.
`user_locale`	Ustawienie języka konta Google w formacie RFC5646, które służy do lokalizowania treści w preferowanym języku użytkownika.

Jeśli na przykład Twój punkt końcowy autoryzacji jest dostępny pod adresem https://myservice.example.com/auth, żądanie może wyglądać tak:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

Aby punkt końcowy autoryzacji obsługiwał żądania logowania, wykonaj te czynności:

Sprawdź, czy client_id jest zgodny z identyfikatorem klienta przypisanym do Google, a redirect_uri jest zgodny z adresem URL przekierowania podanym przez Google dla Twojej usługi. Te kontrole są ważne, aby zapobiec przyznaniu dostępu nieodpowiednim lub nieprawidłowo skonfigurowanym aplikacjom klienckim. Jeśli obsługujesz wiele przepływów OAuth 2.0, sprawdź też, czy wartość parametru response_type to code.
Sprawdź, czy użytkownik jest zalogowany w Twojej usłudze. Jeśli użytkownik nie jest zalogowany, wykonaj czynności konieczne, by się zalogować lub zarejestrować w usłudze.
Wygeneruj kod autoryzacji, którego Google będzie używać do uzyskiwania dostępu do Twojego interfejsu API. Kod autoryzacji może być dowolnym ciągiem znaków, ale musi jednoznacznie reprezentować użytkownika, klienta, dla którego przeznaczony jest token, i czas wygaśnięcia kodu, a także nie może być łatwy do odgadnięcia. Zazwyczaj wydajesz kody autoryzacji, które wygasają po około 10 minutach.

Sprawdź, czy adres URL określony przez parametr redirect_uri ma następującą postać:

  https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
  https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID

Przekierowuje przeglądarkę użytkownika na adres URL określony przez parametr redirect_uri. Podczas przekierowania dołącz wygenerowany kod autoryzacji i oryginalną, niezmienioną wartość stanu, dodając parametry code i state. Oto przykład powstałego adresu URL:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
```

Obsługa żądań wymiany tokenów

Punkt końcowy wymiany tokenów usługi odpowiada za 2 rodzaje wymiany tokenów:

Wymiana kodów autoryzacji na tokeny dostępu i tokeny odświeżania
Wymiana tokenów odświeżania na tokeny dostępu

Żądania wymiany tokenów zawierają te parametry:

Parametry punktu końcowego wymiany tokenów
`client_id`	Ciąg znaków, który identyfikuje źródło żądania jako Google. Ten ciąg znaków musi być zarejestrowany w Twoim systemie jako unikalny identyfikator Google.
`client_secret`	Tajny ciąg znaków zarejestrowany w Google w przypadku Twojej usługi.
`grant_type`	Typ wymienianego tokena. Może to być `authorization_code` lub `refresh_token`.
`code`	Gdy wartość tego parametru to `grant_type=authorization_code`, jest to kod otrzymany przez Google z punktu końcowego logowania lub wymiany tokenów.
`redirect_uri`	Gdy `grant_type=authorization_code`, ten parametr jest adresem URL używanym w początkowym żądaniu autoryzacji.
`refresh_token`	Gdy `grant_type=refresh_token`, ten parametr jest tokenem odświeżania otrzymanym przez Google z punktu końcowego wymiany tokenów.

Wymiana kodów autoryzacji na tokeny dostępu i tokeny odświeżania

Gdy użytkownik zaloguje się, a Twój punkt końcowy autoryzacji zwróci do Google ważny przez krótki czas kod autoryzacji, Google wyśle żądanie do Twojego punktu końcowego wymiany tokenów, aby wymienić kod autoryzacji na token dostępu i token odświeżania.

W przypadku tych żądań wartość parametru grant_type to authorization_code, a wartość parametru code to wartość kodu autoryzacji, który został wcześniej przyznany Google. Oto przykład żądania wymiany kodu autoryzacji na token dostępu i token odświeżania:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Aby wymienić kody autoryzacji na token dostępu i token odświeżania, punkt końcowy wymiany tokenów odpowiada na żądania POST, wykonując te czynności:

Sprawdź, czy client_id identyfikuje źródło żądania jako autoryzowane źródło, a client_secret ma oczekiwaną wartość.
Sprawdź, czy kod autoryzacji jest ważny i nie wygasł oraz czy identyfikator klienta podany w żądaniu jest zgodny z identyfikatorem klienta powiązanym z kodem autoryzacji.
Sprawdź, czy adres URL określony przez parametr redirect_uri jest identyczny z wartością używaną w początkowym żądaniu autoryzacji.
Jeśli nie możesz potwierdzić wszystkich powyższych kryteriów, zwróć błąd HTTP 400 Bad Request z treścią {"error": "invalid_grant"}.
W przeciwnym razie użyj identyfikatora użytkownika z kodu autoryzacji, aby wygenerować token odświeżania i token dostępu. Tokeny mogą mieć dowolną wartość ciągu znaków, ale muszą jednoznacznie reprezentować użytkownika i klienta, dla którego są przeznaczone, oraz nie mogą być możliwe do odgadnięcia. W przypadku tokenów dostępu zapisz też czas wygaśnięcia tokena, który zwykle przypada godzinę po jego wydaniu. Tokeny odświeżania nie mają daty ważności.

W treści odpowiedzi HTTPS zwróć ten obiekt JSON:

{
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"refresh_token": "REFRESH_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}

Google przechowuje token dostępu i token odświeżania użytkownika oraz rejestruje datę wygaśnięcia tokena dostępu. Gdy token dostępu wygaśnie, Google użyje tokena odświeżania, aby uzyskać nowy token dostępu z punktu końcowego wymiany tokenów.

Wymiana tokenów odświeżania na tokeny dostępu

Gdy token dostępu wygaśnie, Google wyśle żądanie do punktu końcowego wymiany tokenów, aby wymienić token odświeżania na nowy token dostępu.

W przypadku tych żądań wartość parametru grant_type to refresh_token, a wartość parametru refresh_token to wartość tokena odświeżania, który został wcześniej przyznany Google. Oto przykład żądania wymiany tokena odświeżania na token dostępu:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

Aby wymienić token odświeżania na token dostępu, punkt końcowy wymiany tokenów odpowiada na żądania POST, wykonując te czynności:

Sprawdź, czy client_id wskazuje, że żądanie pochodzi z Google, a client_secret ma oczekiwaną wartość.
Sprawdź, czy token odświeżania jest prawidłowy i czy identyfikator klienta podany w żądaniu jest zgodny z identyfikatorem klienta powiązanym z tokenem odświeżania.
Jeśli nie możesz potwierdzić wszystkich powyższych kryteriów, zwróć błąd HTTP 400 Bad Request z treścią {"error": "invalid_grant"}.
W przeciwnym razie użyj identyfikatora użytkownika z tokena odświeżania, aby wygenerować token dostępu. Tokeny mogą mieć dowolną wartość ciągu znaków, ale muszą jednoznacznie reprezentować użytkownika i klienta, dla którego są przeznaczone, oraz nie mogą być zgadywalne. W przypadku tokenów dostępu zapisz też czas wygaśnięcia tokena, zwykle godzinę po jego wydaniu.

W treści odpowiedzi HTTPS zwróć ten obiekt JSON:

{
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}

Obsługa żądań informacji o użytkowniku

Punkt końcowy informacji o użytkowniku jest chronionym przez OAuth 2.0 zasobem, który zwraca deklaracje dotyczące połączonego użytkownika. Wdrożenie i hosting punktu końcowego informacji o użytkowniku jest opcjonalne. Wyjątkiem są te przypadki użycia:

Logowanie się na połączone konto za pomocą Google One Tap
Bezproblemowa subskrypcja na AndroidTV.

Po pobraniu tokena dostępu z punktu końcowego tokena Google wysyła żądanie do punktu końcowego informacji o użytkowniku, aby pobrać podstawowe informacje profilowe połączonego użytkownika.

nagłówki żądań punktu końcowego informacji o użytkowniku
`Authorization header`	Token dostępu typu okaziciela.

Jeśli na przykład punkt końcowy informacji o użytkowniku jest dostępny pod adresem https://myservice.example.com/userinfo, żądanie może wyglądać tak:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

Aby punkt końcowy informacji o użytkowniku mógł obsługiwać żądania, wykonaj te czynności:

Wyodrębnij token dostępu z nagłówka autoryzacji i zwróć informacje o użytkowniku powiązanym z tym tokenem.
Jeśli token dostępu jest nieprawidłowy, zwróć błąd HTTP 401 (Brak autoryzacji) i użyj nagłówka odpowiedzi WWW-Authenticate. Poniżej znajduje się przykładowa odpowiedź na pytanie o błąd w informacjach o użytkowniku:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
Jeśli podczas procesu łączenia pojawi się błąd 401 (Brak autoryzacji) lub inna nieudana próba połączenia, błędu nie będzie można odzyskać, pobrany token zostanie odrzucony, a użytkownik będzie musiał ponownie zainicjować proces łączenia.

Jeśli token dostępu jest prawidłowy, zwróć odpowiedź HTTP 200 z podanym niżej obiektem JSON w treści HTTPS odpowiedź:

{
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}

Jeśli punkt końcowy informacji o użytkowniku zwraca odpowiedź HTTP 200, pobrany token i żądania są rejestrowane dla konta Google użytkownika.

odpowiedź dotycząca punktu końcowego informacji o użytkowniku
`sub`	Unikalny identyfikator, który identyfikuje użytkownika w Twoim systemie.
`email`	Adres e-mail użytkownika.
`given_name`	Opcjonalnie: imię użytkownika.
`family_name`	Opcjonalnie: nazwisko użytkownika.
`name`	Opcjonalnie: pełna nazwa użytkownika.
`picture`	Opcjonalnie: zdjęcie profilowe użytkownika.

Sprawdzanie poprawności implementacji

Implementację możesz zweryfikować za pomocą narzędzia OAuth 2.0 Playground.

W narzędziu wykonaj te czynności:

Kliknij Konfiguracja , aby otworzyć okno Konfiguracja OAuth 2.0.
W polu OAuth flow (Proces OAuth) wybierz Client-side (Po stronie klienta).
W polu Punkty końcowe OAuth wybierz Niestandardowe.
W odpowiednich polach podaj punkt końcowy OAuth 2.0 i identyfikator klienta przypisany do Google.
W sekcji Krok 1 nie wybieraj żadnych zakresów Google. Zamiast tego pozostaw to pole puste lub wpisz zakres ważny dla Twojego serwera (albo dowolny ciąg znaków, jeśli nie używasz zakresów OAuth). Gdy skończysz, kliknij Autoryzuj interfejsy API.
W sekcjach Krok 2 i Krok 3 przejdź przez przepływ OAuth 2.0 i sprawdź, czy każdy krok działa zgodnie z oczekiwaniami.

Możesz sprawdzić, czy implementacja jest prawidłowa, korzystając z narzędzia Google Account Linking Demo.