Ta strona została przetłumaczona przez Cloud Translation API.

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:
- punkt końcowy autoryzacji do obsługi żądań autoryzacji.
- punkt końcowy punktu końcowego, aby obsłużyć żądania dostępu i tokenów odświeżania.
- userinfo endpoint (punkt końcowy użytkownika), aby pobierać podstawowe informacje o połączonym koncie użytkownika. Są one wyświetlane użytkownikowi podczas logowania się na powiązane konto.
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.

Wyrażasz zgodę na wyświetlanie połączonych kont podczas logowania się jednym dotknięciem.
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.
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.
Kod autoryzacji Google należy przekazać tokenowi Google z informacjami o koncie Google użytkownika.
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.

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.