Połączenie z kontem Google pozwala właścicielom kont Google szybko, bezproblemowo i bezpiecznie łączyć się z Twoimi usługami oraz udostępniać dane Google.
Logowanie na powiązane konto włącza logowanie jednym dotknięciem przez Google w przypadku użytkowników, którzy mają już połączone konta Google z Twoją usługą. Zwiększa to wygodę użytkowników, ponieważ mogą logować się jednym kliknięciem bez konieczności ponownego wpisywania nazwy użytkownika i hasła. Zmniejsza to też szanse na to, że użytkownicy będą tworzyć zduplikowane konta w Twojej usłudze.
Wymagania
Aby wdrożyć logowanie na połączone konto, musisz spełniać następujące wymagania:
- Masz implementację łączenia OAuth na koncie Google, która obsługuje przepływ kodu autoryzacji OAuth 2.0. Implementacja protokołu OAuth musi obejmować te punkty końcowe:
- punktu końcowego autoryzacji do obsługi żądań autoryzacji.
- punkt końcowy tokena do obsługi żądań dostępu i tokenów odświeżania.
- punkt końcowy informacji o użytkowniku do pobierania podstawowych informacji o powiązanym koncie użytkownika, które są wyświetlane w trakcie procesu logowania się na połączone konto.
- Masz aplikację na Androida.
Jak to działa
Warunek wstępny : użytkownik wcześniej połączył swoje konto Google z kontem w Twojej usłudze.
- Wyrażasz zgodę na wyświetlanie połączonych kont podczas logowania się jednym dotknięciem.
- Użytkownik widzi prośbę o zalogowanie się jednym dotknięciem z opcją zalogowania się w Twojej usłudze za pomocą połączonego konta.
- Jeśli użytkownik zdecyduje się kontynuować korzystanie z połączonego konta, Google wyśle do punktu końcowego tokena żądanie zapisania kodu autoryzacji. Żądanie zawiera token dostępu użytkownika wydany przez Twoją usługę oraz kod autoryzacji Google.
- Wymień kod autoryzacji Google na token identyfikatora Google, który zawiera informacje o koncie Google użytkownika.
- Aplikacja również otrzymuje token identyfikatora po zakończeniu procesu, który dopasowuje go do identyfikatora użytkownika w tokenie identyfikatora otrzymanym przez serwer, aby zalogować użytkownika w aplikacji.
Wdrażanie logowania do połączonego konta w aplikacji na Androida
Aby obsługiwać logowanie się na połączone konto w aplikacji na Androida, postępuj zgodnie z instrukcjami w przewodniku po implementacji na Androidzie.
Obsługa żądań kodu autoryzacji od Google
Google wysyła żądanie POST do punktu końcowego tokena, aby zapisać kod autoryzacji, który wymienisz na token identyfikatora użytkownika. Żądanie zawiera token dostępu użytkownika i kod autoryzacji OAuth2 wydany przez Google.
Zanim zapiszesz kod autoryzacji, sprawdź, czy token dostępu został przez Ciebie przyznany Google. Token ten zawiera 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 obsługiwać te parametry żądania:
| Parametry punktu końcowego tokena | |
|---|---|
code |
Wymagany kod autoryzacji Google OAuth2 |
client_id |
Wymagany identyfikator klienta przekazany Google. |
client_secret |
Wymagany tajny klucz klienta przekazany Google |
access_token |
Wymagany token dostępu, który został wystawiony przez Ciebie dla Google. Dzięki temu poznasz kontekst użytkownika |
grant_type |
Wymagana Wartość MUSI być ustawiona na urn:ietf:params:oauth:grant-type:reciprocal. |
Punkt końcowy wymiany tokenów powinien odpowiadać na żądanie POST w ten sposób:
- Sprawdź, czy dokument
access_tokenzostał przekazany Google zidentyfikowany przezclient_id. - Jeśli żądanie jest prawidłowe, a kod autoryzacji został wymieniony na token identyfikatora Google, prześlij odpowiedź HTTP 200 (OK) lub kod błędu HTTP, jeśli żądanie jest nieprawidłowe.
Odpowiedź HTTP
Gotowe
Zwracanie kodu stanu HTTP 200 OK
Przykładowa odpowiedź o powodzeniu
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{}
Błędy
W przypadku nieprawidłowego żądania HTTP wyślij odpowiedź z jednego z tych kodów błędu HTTP:
| Kod stanu HTTP | Treść | Opis |
|---|---|---|
| 400 | {"error": "invalid_request"} |
W żądaniu brakuje parametru, więc serwer nie może go zrealizować. Ten kod może być też zwracany, jeśli żądanie zawiera nieobsługiwany parametr lub powtarza parametr |
| 401 | {"error": "invalid_request"} |
Uwierzytelnianie klienta się nie udało, na przykład jeśli żądanie zawiera nieprawidłowy identyfikator lub tajny klucz klienta |
| 401 | {"error": "invalid_token"}
Umieść test uwierzytelniania „WWW-Authentication: Bearer” w nagłówku odpowiedzi |
Token dostępu partnera jest nieprawidłowy. |
| 403 | {"error": "insufficient_permission"}
Umieść test uwierzytelniania „WWW-Authentication: Bearer” w nagłówku odpowiedzi |
Token dostępu partnera nie zawiera zakresów niezbędnych do wykonania wzajemnego protokołu OAuth |
| 500 | {"error": "internal_error"} |
Błąd serwera |
Odpowiedź o błędzie powinna zawierać te pola :
| Pola odpowiedzi na błędy | |
|---|---|
error |
Wymagany – ciąg znaków błędu |
error_description |
zrozumiały dla człowieka opis błędu; |
error_uri |
Identyfikator URI zawierający więcej informacji o błędzie |
Przykładowy 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."
}
Wymiana kodu autoryzacji dla tokena identyfikatora
Musisz wymienić otrzymany kod autoryzacji na token identyfikatora Google, który zawiera informacje o koncie Google użytkownika.
Aby wymienić kod autoryzacji na token identyfikatora Google, wywołaj punkt końcowy https://oauth2.googleapis.com/token i ustaw te parametry:
| Pola żądania | |
|---|---|
client_id |
Wymagany: identyfikator klienta uzyskany ze strony Dane logowania w Konsoli interfejsów API. Zwykle są to dane logowania o nazwie Nowe działania w aplikacji Actions on Google. |
client_secret |
Wymagany: tajny klucz klienta uzyskany ze strony Dane logowania w konsoli API. |
code |
Wymagany – kod autoryzacji wysłany w pierwszym żądaniu. |
grant_type |
Wymagane Zgodnie ze specyfikacją OAuth 2.0 wartość tego pola musi być ustawiona na 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
Google w odpowiedzi na to żądanie zwraca obiekt JSON zawierający token dostępu o ograniczonym czasie ważności i token odświeżania.
Odpowiedź zawiera te pola:
| Pola odpowiedzi | |
|---|---|
access_token |
Token dostępu wydany przez Google, który Twoja aplikacja wysyła w celu autoryzacji żądania do interfejsu API Google. |
id_token |
Token identyfikatora zawiera informacje o koncie Google użytkownika. Sekcja Weryfikowanie odpowiedzi zawiera szczegółowe informacje o dekodowaniu i weryfikowaniu odpowiedzi tokena identyfikatora. |
expires_in |
Pozostały czas życia tokena dostępu w sekundach |
refresh_token |
Token, za pomocą którego można uzyskać nowy token dostępu. Tokeny odświeżania są ważne do momentu unieważnienia dostępu przez użytkownika |
scope |
W przypadku logowania na połączone konto wartość tego pola 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
Weryfikowanie odpowiedzi tokena identyfikatora
Weryfikowanie i dekodowanie potwierdzenia JWT
Potwierdzenie JWT możesz zweryfikować i zdekodować za pomocą Biblioteka dekodowania JWT dla Twojego języka Używaj Klucze publiczne Google, dostępne w tych krajach: JWK lub formaty PEM do weryfikacji, podpis tokena.
Po zdekodowaniu potwierdzenie JWT wygląda jak w tym 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
wydawca (pole iss) to https://accounts.google.com, oznacza to, że odbiorcy
(pole aud) to przypisany identyfikator klienta, który nie wygasł.
(pole exp).
Za pomocą pól email, email_verified i hd możesz określić,
Google hostuje dany adres e-mail i jest dla niego autorytatywny. W przypadku, gdy Google
autorytatywny, według którego użytkownik jest obecnie znany jako rzeczywisty właściciel konta
i możesz pominąć hasło i inne testy zabezpieczające. W przeciwnym razie te metody
mogą zostać użyte do zweryfikowania konta przed połączeniem.
Przypadki, w których Google ma wiarygodność:
- To jest konto Gmail, adres
emailma sufiks@gmail.com. - To jest konto G Suite,
email_verifiedma wartość prawda i ustawionohd.
Użytkownicy mogą rejestrować się w Google, nie korzystając z Gmaila lub G Suite. Kiedy
email nie zawiera sufiksu @gmail.com, a hd nie występuje w Google
zalecamy wiarygodność i hasło lub inne metody weryfikujące weryfikację
użytkownika. email_verified może również być prawdziwe, ponieważ wstępnie zweryfikowaliśmy, że
użytkownika przy tworzeniu konta Google, jednak własność firmy zewnętrznej
konto e-mail mogło się od tego czasu zmienić.