Konta są łączone za pomocą standardowych w branży przepływów niejawnych i kodów autoryzacji OAuth 2.0. Twoja usługa musi obsługiwać punkty końcowe autoryzacji i wymiany tokenów zgodne z OAuth 2.0.
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:
- 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.
- 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.
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:
- Kliknij Utwórz projekt.
- Wpisz nazwę lub zaakceptuj wygenerowaną sugestię.
- Potwierdź lub zmień pozostałe pola.
- Kliknij Utwórz.
Aby wyświetlić identyfikator projektu:
- Znajdź projekt w tabeli na stronie docelowej. Identyfikator projektu jest wyświetlany w kolumnie Identyfikator.
Konfigurowanie ekranu zgody OAuth
Proces łączenia konta Google obejmuje ekran akceptacji, na którym użytkownicy mogą zobaczyć, która aplikacja prosi o dostęp do ich danych, jakiego rodzaju dane są wymagane oraz jakie warunki mają zastosowanie. Zanim wygenerujesz identyfikator klienta interfejsu API Google, musisz skonfigurować ekran zgody OAuth.
- Otwórz stronę Ekran zgody OAuth w konsoli interfejsów API Google.
- Jeśli pojawi się taka prośba, wybierz utworzony projekt.
Na stronie „Ekran zgody OAuth” wypełnij formularz i kliknij przycisk „Zapisz”.
Nazwa aplikacji: nazwa aplikacji, która prosi o zgodę. Nazwa powinna dokładnie odzwierciedlać 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 połączenie kont.
Logo aplikacji: obraz na ekranie zgody, który ułatwia użytkownikom rozpoznanie aplikacji. Logo jest wyświetlane na ekranie zgody na połączenie konta i w ustawieniach konta.
Adres e-mail pomocy: dla użytkowników do kontaktowania się z Tobą w sprawie pytań o ich zgodę.
Zakresy interfejsów API Google: zakresy umożliwiają aplikacji dostęp do prywatnych danych użytkownika w Google. W przypadku łączenia kont Google wystarczy domyślny zakres (email, profile, openid). Nie musisz dodawać żadnych zakresów zawierających dane wrażliwe. Zwykle zaleca się, aby prosić o zakresy przyrostowo, w momencie, gdy dostęp jest wymagany, 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 aplikacji muszą być hostowane w autoryzowanych domenach. Więcej informacji
Link do strony głównej aplikacji: strona główna aplikacji. Musi być hostowany w autoryzowanej domenie.
Link do polityki prywatności aplikacji: wyświetlany na ekranie zgody na łączenie kont Google. Musi być hostowany w autoryzowanej domenie.
Link do warunków korzystania z aplikacji (opcjonalnie): musi być hostowany w autoryzowanej domenie.
Rysunek 1. Ekran zgody na łączenie kont Google w fikcyjnej aplikacji Tunery
Sprawdź „Stan weryfikacji”. Jeśli Twoja aplikacja wymaga weryfikacji, kliknij przycisk „Prześlij do weryfikacji”, aby przesłać ją do weryfikacji. Szczegółowe informacje znajdziesz w wymaganiach dotyczących weryfikacji OAuth.
Wdrożenie serwera OAuth
To support the OAuth 2.0 implicit flow, your service makes an authorization endpoint available by HTTPS. This endpoint is responsible for authentication and obtaining consent from users for data access. The authorization endpoint presents a sign-in UI to your users that aren't already signed in and records consent to the requested access.
When a Google application needs to call one of your service's authorized APIs, Google uses this endpoint to get permission from your users to call these APIs on their behalf.
A typical OAuth 2.0 implicit flow session initiated by Google has the following flow:
- Google opens your authorization endpoint in the user's browser. The user signs in, if not signed in already, and grants Google permission to access their data with your API, if they haven't already granted permission.
- Your service creates an access token and returns it to Google. To do so, redirect the user's browser back to Google with the access token attached to the request.
- Google calls your service's APIs and attaches the access token with each request. Your service verifies that the access token grants Google authorization to access the API and then completes the API call.
Handle authorization requests
When a Google application needs to perform account linking via an OAuth 2.0 implicit flow, Google sends the user to your authorization endpoint with a request that includes the following parameters:
| Authorization endpoint parameters | |
|---|---|
client_id |
The client ID you assigned to Google. |
redirect_uri |
The URL to which you send the response to this request. |
state |
A bookkeeping value that is passed back to Google unchanged in the redirect URI. |
response_type |
The type of value to return in the response. For the OAuth 2.0 implicit
flow, the response type is always token. |
user_locale |
The Google Account language setting in RFC5646 format used to localize your content in the user's preferred language. |
For example, if your authorization endpoint is available at
https://myservice.example.com/auth, a request might look like the following:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE
For your authorization endpoint to handle sign-in requests, do the following steps:
Verify the
client_idandredirect_urivalues to prevent granting access to unintended or misconfigured client apps:- Confirm that the
client_idmatches the client ID you assigned to Google. - Confirm that the URL specified by the
redirect_uriparameter has the following form:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Confirm that the
Check if the user is signed in to your service. If the user isn't signed in, complete your service's sign-in or sign-up flow.
Generate an access token for Google to use to access your API. The access token can be any string value, but it must uniquely represent the user and the client the token is for and must not be guessable.
Send an HTTP response that redirects the user's browser to the URL specified by the
redirect_uriparameter. Include all of the following parameters in the URL fragment:access_token: The access token you just generatedtoken_type: The stringbearerstate: The unmodified state value from the original request
The following is an example of the resulting URL:
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
Google's OAuth 2.0 redirect handler receives the access token and confirms
that the state value hasn't changed. After Google has obtained an
access token for your service, Google attaches the token to subsequent calls
to your service APIs.
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: 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.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Jeśli token dostępu jest prawidłowy, zwróć odpowiedź HTTP 200 z podanym niżej obiektem JSON w treści HTTPS odpowiedź:
Jeśli punkt końcowy informacji o użytkowniku zwraca odpowiedź HTTP 200, pobrany token i żądania są rejestrowane dla konta Google użytkownika.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }odpowiedź dotycząca punktu końcowego informacji o użytkowniku subUnikalny identyfikator, który identyfikuje użytkownika w Twoim systemie. emailAdres e-mail użytkownika. given_nameOpcjonalnie: imię użytkownika. family_nameOpcjonalnie: nazwisko użytkownika. nameOpcjonalnie: pełna nazwa użytkownika. pictureOpcjonalnie: zdjęcie profilowe użytkownika.
Weryfikowanie implementacji
Własną implementację możesz sprawdzić za pomocą narzędzia OAuth 2.0 Playground.
W narzędziu wykonaj te czynności:
- Kliknij Konfiguracja , aby otworzyć okno konfiguracji OAuth 2.0.
- W polu Procedura OAuth wybierz 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 uprawnień Google. Zamiast tego pozostaw to pole puste lub wpisz zakres prawidłowy dla Twojego serwera (lub dowolny ciąg znaków, jeśli nie używasz zakresów OAuth). Gdy skończysz, kliknij Autoryzuj interfejsy API.
- W sekcji Krok 2 i Krok 3 przejdź przez proces OAuth 2.0 i sprawdź, czy każdy krok działa prawidłowo.
Implementację możesz zweryfikować za pomocą narzędzia Demo łączenia kont Google.
W narzędziu wykonaj te czynności:
- Kliknij przycisk Zaloguj się przez Google.
- Wybierz konto, które chcesz połączyć.
- Wpisz identyfikator usługi.
- Opcjonalnie wpisz co najmniej 1 zakres, do którego chcesz uzyskać dostęp.
- Kliknij Uruchom wersję pokazową.
- Gdy pojawi się odpowiedni komunikat, potwierdź, że możesz wyrazić zgodę lub odrzucić prośbę o połączenie.
- Sprawdź, czy nastąpiło przekierowanie na Twoją platformę.