Logowanie na powiązane konto

Uwaga: Funkcja One Tap na urządzeniach z Androidem została wycofana. Aby zapewnić bezpieczeństwo i łatwość obsługi aplikacji, migracja do Credential Manager (Menedżer danych logowania). Menedżer danych logowania obsługuje klucze dostępu, hasła uwierzytelnianie sfederowane (np. Zaloguj się przez Google), silniejsze i zwiększyć wygodę użytkowników.

Łą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.

Uwaga: logowanie się na połączone konto jest możliwe tylko na urządzeniach z Androidem.

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.

1. Wyrażasz zgodę na wyświetlanie połączonych kont podczas logowania jednym dotknięciem.
2. Pojawia się prośba o zalogowanie się jednym dotknięciem z opcją zalogowania się w usłudze przy użyciu powiązanego 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. Wymieniasz kod autoryzacji Google na token identyfikatora Google, który zawiera informacje o koncie Google użytkownika.
5. 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.

.

Uwaga: kroki 3 i 4 są stosowane przy pierwszej próbie zalogowania się na połączone konto. Te czynności są pomijane w przypadku kolejnego logowania się na to samo konto.

Rysunek 1. Proces logowania na połączone konto. Jeśli użytkownik ma na urządzeniu wiele zalogowanych kont, może zobaczyć opcję wyboru konta i zostanie przekierowany do widoku logowania połączonego konta tylko wtedy, gdy wybierze połączone konto.

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

Uwaga: aby wykonać poniższe czynności, musisz zarejestrować punkty końcowe OAuth2 w 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:

Uwaga: wymaga to aktualizacji punktu końcowego tokena. W żądaniu tokena OAuth połączenia konta Google Google wywołuje punkt końcowy tokena, aby wymienić podany przez Ciebie kod autoryzacji na token dostępu lub odświeżania. W żądaniu tokena logowania połączonego konta Google wywołuje punkt końcowy tokena, aby zapisać kod autoryzacji.

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_token został przyznany Google, co potwierdza client_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": "[e-mail]", // 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 email ma sufiks @gmail.com.
• To jest konto G Suite, email_verified ma wartość prawda i ustawiono hd.

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ć.