Ostrzeżenie: te dane są dostarczane zgodnie z Polityką danych użytkownika Google . Zapoznaj się z zasadami i przestrzegaj ich. Niezastosowanie się do tego może spowodować zawieszenie projektu lub zawieszenie konta.

Logowanie się na połączone konto

Łączenie kont Google umożliwia właścicielom kont Google szybkie, bezproblemowe i bezpieczne łączenie się z usługami oraz udostępnianie danych Google.

Logowanie za pomocą połączonego konta umożliwia logowanie jednym dotknięciem przez Google w przypadku użytkowników, którzy mają już konto Google połączone z usługą. Jest to wygodne dla użytkowników, ponieważ mogą logować się jednym kliknięciem bez konieczności ponownego wprowadzania nazwy użytkownika i hasła. Zmniejsza to także ryzyko utworzenia duplikatów kont w usłudze.

Wymagania

Aby zaimplementować funkcję Połączone konto, musisz spełniać te wymagania:

  • Masz implementację łączenia kont OAuth Google, która obsługuje przepływ kodu autoryzacji OAuth 2.0. Implementacja protokołu OAuth musi obejmować takie punkty końcowe:
  • Masz aplikację na Androida.

Jak to działa

Wymagania wstępne : użytkownik wcześniej połączył swoje konto Google z kontem w usłudze.

  1. Wyrażasz zgodę na wyświetlanie połączonych kont podczas logowania się jednym dotknięciem.
  2. Użytkownik otrzymuje prośbę o zalogowanie się za pomocą jednego kliknięcia z możliwością zalogowania się w Twojej usłudze za pomocą połączonego konta.
  3. Jeśli użytkownik zdecyduje się kontynuować korzystanie z połączonego konta, Google wyśle żądanie do punktu końcowego tokena, aby zapisać kod autoryzacji. Żądanie zawiera token dostępu użytkownika wydany przez Twoją usługę oraz kod autoryzacji Google.
  4. Kod autoryzacji Google należy przekazać tokenowi Google z informacjami o koncie Google użytkownika.
  5. Twoja aplikacja otrzyma też token identyfikatora, gdy proces dobiegnie końca i skojarzysz go z identyfikatorem użytkownika w tokenie identyfikatora otrzymanym przez serwer, aby zalogować użytkownika do aplikacji.
Połączone konto.
Rysunek 1. Proces logowania się na połączone konto. Jeśli użytkownik ma na swoim urządzeniu wiele kont zalogowanych, może zobaczyć listę wyboru kont i przejść do widoku Połączone konto tylko wtedy, gdy wybierze połączone konto.

Wdrażanie logowania się na połączone konta w aplikacji na Androida

Aby obsługiwać logowanie się przez połączone konto w aplikacji na Androida, wykonaj instrukcje podane w Przewodniku po implementacji Androida.

Obsługa żądań kodu autoryzacji od Google

Google wysyła żądanie POST do punktu końcowego tokena, by zapisać kod autoryzacji, który można wymienić dla tokena identyfikatora użytkownika. Żądanie zawiera token dostępu użytkownika oraz wydany przez Google kod autoryzacji OAuth2.

Zanim zapiszesz kod autoryzacji, potwierdź, że token dostępu został przyznany przez Google na podstawie: client_id.

Żądanie HTTP

Przykładowe żądanie

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

code=GOOGLE_AUTHORIZATION_CODE
&grant_type=urn:ietf:params:oauth:grant-type:reciprocal
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&access_token=ACCESS_TOKEN

Punkt końcowy wymiany tokenów musi mieć możliwość obsługi następujących parametrów żądania:

Parametry punktu końcowego tokena
code Wymagany kod autoryzacji Google OAuth2
client_id Wymagany identyfikator klienta otrzymany od Google
client_secret Wymagany tajny klucz klienta przesłany do Google
access_token Wymagany token dostępu wydany przez Google. Użyjesz go, aby poznać kontekst użytkownika.
grant_type Wymagany Wartość MUSI być ustawiona na urn:ietf:params:oauth:grant-type:reciprocal

Punkt końcowy wymiany tokenów powinien odpowiadać na żądanie POST, wykonując następujące czynności:

  • Sprawdź, czy numer access_token został przyznany Google na podstawie identyfikatora client_id.
  • Odpowiedz przy użyciu odpowiedzi HTTP 200 (OK), jeśli żądanie jest prawidłowe i kod uwierzytelnienia zostanie zastąpiony tokenem identyfikatora Google, lub kodu błędu HTTP, jeśli żądanie będzie nieprawidłowe.

Odpowiedź HTTP

Sukces

Zwracanie kodu stanu HTTP 200 OK

Przykładowa odpowiedź
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{}

Błędy

W przypadku nieprawidłowego żądania HTTP w odpowiedzi podaj jeden z tych kodów błędów HTTP:

Kod stanu HTTP Karoseria Opis
400 {"error": "invalid_request"} W żądaniu brakuje parametru, więc serwer nie może kontynuować żądania. Ten komunikat może też zostać zwrócony, jeśli żądanie zawiera nieobsługiwany parametr lub powtarza parametr.
401 {"error": "invalid_request"} Nie udało się uwierzytelnić klienta, na przykład jeśli żądanie zawiera nieprawidłowy identyfikator klienta lub tajny klucz klienta.
401 {"error": "invalid_token"}

Uwzględnij w nagłówku odpowiedzi „&WtW-Authentication: Bearer" auth”

Token dostępu partnera jest nieprawidłowy.
403 {"error": "insufficient_permission"}

Uwzględnij w nagłówku odpowiedzi „&WtW-Authentication: Bearer" auth”

Token dostępu partnera nie zawiera zakresów, które są niezbędne do przeprowadzenia tego działania
500 {"error": "internal_error"} Błąd serwera

Odpowiedź o błędzie powinna zawierać następujące pola :

Pola błędu
error Wymagany Ciąg błędów
error_description Czytelny opis błędu przez człowieka
error_uri Identyfikator URI zawierający więcej informacji o błędzie
Przykładowa odpowiedź na błąd 400
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_request",
  "error_description": "Request was missing the 'access_token' parameter."
}

Kod autoryzacji wymiany tokena

Musisz uzyskać otrzymany kod autoryzacji dla tokena Google ID, który zawiera informacje o koncie Google użytkownika.

Aby wymienić kod autoryzacji tokena Google ID, wywołaj punkt końcowy https://oauth2.googleapis.com/token i skonfiguruj te parametry:

Pola żądań
client_id Wymagany – identyfikator klienta uzyskany ze strony Dane logowania w konsoli API. Zwykle są to dane logowania o nazwie New Actions on Google App (Nowe działania w aplikacji Google).
client_secret Wymagany – tajny klucz klienta pobrany ze strony Dane logowania w konsoli API
code Wymagane kod autoryzacji wysłany we wstępnym żądaniu
grant_type Wymagane zgodnie z definicją w specyfikacji OAuth 2.0 to pole musi zawierać wartość authorization_code.
Przykładowe żądanie
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=GOOGLE_AUTHORIZATION_CODE
&grant_type=authorization_code
&client_id=GOOGLE_CLIENT_ID
&client_secret=GOOGLE_CLIENT_SECRET

W odpowiedzi na to żądanie Google zwraca obiekt JSON zawierający token dostępu na krótki czas i token odświeżania.

Odpowiedź zawiera następujące pola:

Pola odpowiedzi
access_token Przyznany przez Google token dostępu, który aplikacja wysyła w celu autoryzacji żądania do interfejsu Google API
id_token Token identyfikatora zawiera informacje o koncie Google użytkownika. Sekcja Zweryfikuj odpowiedź zawiera szczegółowe informacje o tym, jak zdekodować i zweryfikować odpowiedź tokena tożsamości.
expires_in Pozostały czas życia tokena dostępu w sekundach
refresh_token Token, za pomocą którego możesz uzyskać nowy token dostępu. Tokeny odświeżania są ważne do momentu anulowania dostępu użytkownika
scope W tym przypadku wartość w tym polu jest zawsze ustawiona na „openid”
token_type Typ zwracanego tokena. Obecnie wartość tego pola jest zawsze ustawiona na Bearer
Przykładowa odpowiedź
HTTP/1.1 200 OK
Content-type: application/json; charset=utf-8

{
  "access_token": "Google-access-token",
  "id_token": "Google-ID-token",
  "expires_in": 3599,
  "token_type": "Bearer",
  "scope": "openid",
  "refresh_token": "Google-refresh-token"
}


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

code=Google authorization code
&grant_type=authorization_code
&client_id=Google client id
&client_secret=Google client secret

Zweryfikuj odpowiedź tokena tożsamości

Sprawdź poprawność i zdekoduj asercję JWT

Potwierdzenie JWT można sprawdzić i zdekodować, używając biblioteki dekodującej JWT dla swojego języka . Użyj kluczy publicznych Google, dostępnych w formatach JWK lub PEM , aby zweryfikować podpis tokena.

Po zdekodowaniu asercja JWT wygląda jak w następującym przykładzie:

{
  "sub": "1234567890",      // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "email_verified": true,   // true, if Google has verified the email address
  "hd": "example.com",      // If present, the host domain of the user's GSuite email address
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ",
  "locale": "en_US"         // User's locale, from browser or phone settings
}

Oprócz weryfikacji podpisu tokena sprawdź, czy wystawca potwierdzenia (pole iss ) to https://accounts.google.com , czy odbiorca (pole aud ) to przypisany przez Ciebie identyfikator klienta oraz czy token nie wygasł ( exp pole).

Korzystając z pól email , email_verified i hd możesz określić, czy Google obsługuje adres e-mail i czy jest miarodajny. W przypadkach, gdy Google jest autorytatywnym użytkownikiem, wiadomo, że użytkownik jest prawowitym właścicielem konta i możesz pominąć hasło lub inne metody sprawdzania. W przeciwnym razie te metody mogą służyć do weryfikacji konta przed połączeniem.

Przypadki, w których Google jest autorytatywny:

  • email ma przyrostek @gmail.com , to jest konto Gmail.
  • email_verified ma wartość true i ustawiono hd , to jest konto G Suite.

Użytkownicy mogą rejestrować się na konta Google bez korzystania z Gmaila ani G Suite. Jeśli email nie zawiera sufiksu @gmail.com i nie ma hd Google nie jest autorytatywny i zaleca się podanie hasła lub innych metod sprawdzania tożsamości w celu zweryfikowania użytkownika. email_verfied może również mieć wartość true, ponieważ firma Google wstępnie zweryfikowała użytkownika podczas tworzenia konta Google, jednak własność konta e-mail innej firmy mogła ulec zmianie od tego czasu.