Łączenie kont Google pozwala właścicielom kont Google szybko, bezproblemowo i bezpiecznie łączyć się z usługami oraz udostępniać dane Google.
Logowanie się na połączone konto umożliwia logowanie się jednym dotknięciem przez Google w przypadku użytkowników, którzy mają już swoje konta Google połączone z Twoją usługą. Zwiększa to wygodę użytkowników, którzy mogą zalogować się 1 kliknięciem bez konieczności ponownego wpisywania nazwy użytkownika i hasła. Zmniejsza to też szanse na utworzenie zduplikowanych kont w Twojej usłudze przez użytkowników.
Wymagania
Aby zaimplementować logowanie się na połączone konto, musisz spełnić te wymagania:
- Masz wdrożenie łączenia protokołu OAuth na koncie Google, które obsługuje przepływ kodu autoryzacji OAuth 2.0. Implementacja protokołu OAuth musi obejmować te punkty końcowe:
- punkt końcowy autoryzacji do obsługi żądań autoryzacji.
- token endpoint (Punkt końcowy tokena) do obsługi żądań tokenów dostępu i odświeżania.
- userinfopoint, aby pobrać podstawowe informacje o połączonym koncie, które są wyświetlane użytkownikowi podczas logowania się na połączone konto.
- Masz aplikację na Androida.
Jak to działa
Warunek wstępny : użytkownik połączył już swoje konto Google z kontem w Twojej usłudze.
- Wyrażasz zgodę na wyświetlanie połączonych kont podczas logowania jednym dotknięciem.
- Pojawia się prośba o zalogowanie się jednym dotknięciem z opcją zalogowania się w usłudze przy użyciu powiązanego konta.
- 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.
- Wymieniasz kod autoryzacji Google na token identyfikatora Google, który zawiera informacje o koncie Google użytkownika.
- Po zakończeniu procesu Twoja aplikacja również otrzymuje token identyfikatora. Porównujesz go z identyfikatorem użytkownika w tokenie identyfikatora otrzymanym przez serwer w celu zalogowania użytkownika w aplikacji.
Wdrażanie logowania na połączone konto w aplikacji na Androida
Aby umożliwić logowanie się na połączone konto w aplikacji na Androida, postępuj zgodnie z instrukcjami podanymi w przewodniku po implementacji na Androidzie.
Obsługa żądań kodu autoryzacji pochodzących od Google
Google wysyła żądanie POST do punktu końcowego tokena, aby zapisać kod autoryzacji, który wymieniasz na token identyfikatora użytkownika. Żądanie zawiera token dostępu użytkownika i kod autoryzacji OAuth2 wydany przez Google.
Zanim zapiszesz kod autoryzacji, musisz sprawdzić, czy token dostępu został przez Ciebie przyznany Google zgodnie z identyfikatorem 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ć następujące parametry żądania:
| Parametry punktu końcowego tokena | |
|---|---|
code |
Wymagany kod autoryzacji Google OAuth2 |
client_id |
Wymagany identyfikator klienta wystawiony przez Ciebie Google |
client_secret |
Wymagany tajny klucz klienta, który został przez Ciebie przekazany Google. |
access_token |
Wymagany – token dostępu wydany przez Ciebie dla Google. Pozwoli Ci to poznać kontekst |
grant_type |
Wymagane Wartość MUSI być ustawiona na urn:ietf:params:oauth:grant-type:reciprocal |
Punkt końcowy wymiany tokenów powinien odpowiedzieć na żądanie POST w następujący sposób:
- Sprawdź, czy dokument
access_tokenzostał przyznany Google, co potwierdzaclient_id. - Wysyłaj odpowiedź HTTP 200 (OK), jeśli żądanie jest prawidłowe, a kod autoryzacji został zamieniony na token identyfikatora Google, lub kodem błędu HTTP, jeśli żądanie jest nieprawidłowe.
Odpowiedź HTTP
Sukces
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 w odpowiedzi podaj jeden z tych kodów błędów HTTP:
| Kod stanu HTTP | Treść | Opis |
|---|---|---|
| 400 | {"error": "invalid_request"} |
W żądaniu brakuje parametru, więc serwer nie może go zrealizować. Ten błąd może też pojawić się, gdy żądanie zawiera nieobsługiwany parametr lub powtórzy ten parametr. |
| 401 | {"error": "invalid_request"} |
Nie udało się uwierzytelnić klienta, na przykład jeśli żądanie zawiera nieprawidłowy identyfikator lub nieprawidłowy klucz klienta. |
| 401 | {"error": "invalid_token"}
Dołącz tekst „WWW-Authentication: Bearer” test zabezpieczający uwierzytelnianie w nagłówku odpowiedzi |
Token dostępu partnera jest nieprawidłowy. |
| 403 | {"error": "insufficient_permission"}
Dołącz tekst „WWW-Authentication: Bearer” test zabezpieczający uwierzytelnianie w nagłówku odpowiedzi |
Token dostępu partnera nie zawiera zakresów niezbędnych do przeprowadzenia wzajemnej autoryzacji OAuth |
| 500 | {"error": "internal_error"} |
Błąd serwera |
Odpowiedź dotycząca błędu powinna zawierać te pola :
| Pola odpowiedzi na błędy | |
|---|---|
error |
Wymagany ciąg 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ł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 giełdy dla tokena tożsamości
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 Konsoli interfejsów API. Zwykle będą to dane logowania o nazwie Nowa aplikacja Actions on Google |
client_secret |
Wymagany – tajny klucz klienta uzyskany ze strony Dane logowania konsoli interfejsów API. |
code |
Wymagany – kod autoryzacji wysłany w pierwszym żądaniu |
grant_type |
Wymagane Zgodnie z definicją w specyfikacji protokołu 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
W odpowiedzi na to żądanie Google zwraca obiekt JSON zawierający token dostępu o krótkim czasie ważności i token odświeżania.
Odpowiedź zawiera te pola:
| Pola odpowiedzi | |
|---|---|
access_token |
Token dostępu wysłany przez Google, który jest wysyłany przez aplikację w celu autoryzowania żądania do interfejsu API Google |
id_token |
Token identyfikatora zawiera informacje o koncie Google użytkownika. Sekcja Weryfikacja odpowiedzi zawiera szczegółowe informacje o tym, jak zdekodować i zweryfikować odpowiedź tokena identyfikatora. |
expires_in |
Pozostały czas ważności tokena dostępu (w sekundach) |
refresh_token |
Token, którego możesz użyć do uzyskania nowego tokena dostępu. Tokeny odświeżania są ważne, dopóki użytkownik nie anuluje dostępu |
scope |
W przypadku użycia funkcji logowania się na połączone konto jego wartość jest zawsze ustawiona na openid. |
token_type |
Typ zwróconego 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 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ć.