Przepływ użytkowników uwierzytelniania

Opis

Proces uwierzytelniania ma na celu identyfikację i uwierzytelnianie użytkownika w integratorze płatności (integratorze płatności).

Uwierzytelnianie to dane wejściowe innych metod. Dotyczy to zwłaszcza associateAccount i capture. Oznacza to, że dowód uwierzytelniania jest używany jako dane wejściowe (parametr) tych 2 metod.

Google może też zweryfikować użytkownika za pomocą procesu uwierzytelniania w trybie samodzielnym. W takim przypadku nie jest ona używana jako dane wejściowe w żadnym innym procesie, a jedynie w celu sprawdzenia, czy użytkownik może uwierzytelnić tę tożsamość.

Pamiętaj, że podczas rejestracji Google pomoże Ci wybrać mechanizm uwierzytelniania, który najlepiej pasuje do Twojego produktu.

Jak to działa

Istnieją 2 sposoby uwierzytelniania użytkownika – każdy z nich przebiega w inny sposób. Podczas integracji integrator musi określić, którego użyć.

1. Uwierzytelnianie przekierowania
2. Uwierzytelnianie SMS-MT za pomocą hasła jednorazowego

Uwierzytelnianie przekierowania

Użytkownik Google, który potrzebuje uwierzytelniania, może zostać przekierowany do aplikacji integratora lub jego witryny w celu zweryfikowania tożsamości. Oto krótkie omówienie tego procesu:

1. Google przekierowuje użytkownika do aplikacji internetowej lub aplikacji na Androida integratora, w której może zostać uwierzytelniony.
2. Do uwierzytelnienia służy uwierzytelnianie requestId (od AuthenticationRequest).
3. Spowoduje to utworzenie podpisanej odpowiedzi o nazwie AuthenticationResponse.
4. Następnie aplikacja lub strona przekierowuje użytkownika z powrotem do Google.

Uwaga: w trybie samodzielnym podpisana odpowiedź (krok 3) oraz gspResult określają, czy uwierzytelnianie się udało.

Uwierzytelnianie przekierowania korzysta z metody HTTP GET z parametrami kodowanymi w adresie URL aplikacji internetowej. Wykorzystuje intencję Androida do uwierzytelniania aplikacji na Androida. Więcej informacji o kodowaniu znajdziesz w sekcji Uwierzytelnianie internetowe. Informacje o parametrach intencji Androida – Uwierzytelnianie na Androidzie.

Wynikiem każdego z tych mechanizmów uwierzytelniania jest podpisana odpowiedź o nazwie AuthenticationResponse. Intencja powinna zawierać zaszyfrowaną, zakodowaną odpowiedź na uwierzytelnianie standardowego uwierzytelniania Google Payments (gspAuthenticationResponse), aby przekazywać informacje na temat udanego uwierzytelnienia. Jeśli są używane w trybie samodzielnym, do określenia pomyślnego uwierzytelnienia służą gspResult i podpis.

Uwaga: integrator musi udostępnić swoją aplikację internetową zarówno w wersji na komórki, jak i na komputery.

Poniższy diagram przedstawia interakcję między przeglądarką użytkownika, Google i aplikacją internetową integratora:

Proces uwierzytelniania przekierowania do internetu

Oto lista obiektów i ich reprezentacji:

• Użytkownik: osoba, która chce dodać formę płatności do swojego konta Google.
• Interfejs Google: w tym przypadku jest to interfejs internetowy Google, w którym klient zaczyna konfigurować formę płatności.
• Serwer Google: serwer backendu Google, który sprawdza uwierzytelnianie oraz inne zadania związane z uwierzytelnianiem.
• Internet integratora płatności: witryna integratora, w której użytkownik ma konto.

W ramach tego procesu uwierzytelniania zakładamy już, że użytkownik jest na stronie Google (interfejsie Google) i próbuje dodać formę płatności. Tu wszystko się zaczyna.

1. Interfejs Google tworzy adres URL uwierzytelniania, który jest wysyłany do serwera Google (backendu). To właśnie aktywuje proces uwierzytelniania.
2. Serwer Google tworzy żądanie uwierzytelniania (AuthenticationRequest).
3. Żądanie uwierzytelniania wysłane do interfejsu Google.
4. Użytkownik otrzymuje prośbę o uwierzytelnienie swojego identyfikatora u integratora.
5. Użytkownik odpowiada, że chce się uwierzytelnić, co wysyła tę wiadomość do witryny integratora.
6. Strona integratora płatności prosi o weryfikację tożsamości użytkownika.
7. Użytkownik dostarcza dokument potwierdzający swoją tożsamość, który jest wysyłany na stronę integratora płatności.
8. Integrator tworzy odpowiedź (authenticationResponse) na dostarczone dowody (znak authenticationResponse zakodowany w wiadomości).
9. Ten adres URL odpowiedzi jest wysyłany do użytkownika.
10. Adres URL odpowiedzi jest natychmiast wysyłany od użytkownika do interfejsu Google.
11. Interfejs Google wysyła odpowiedź do serwera Google.
12. Serwer Google interpretuje odpowiedź jako zweryfikowaną.

Następny schemat sekwencji przedstawia interakcję między telefonem użytkownika, Google i aplikacją na Androida integratora:

Przekierowywanie uwierzytelniania w aplikacji na Androida

Uwaga: żaden z 2 powyższych diagramów nie pokazuje użycia authenticationId jako danych wejściowych w innym procesie, ale najczęściej tak właśnie jest.

Obiekty i ich znaczenie:

• Użytkownik: osoba, która chce dodać formę płatności do swojego konta Google.
• Interfejs Google: w tym przypadku jest to interfejs aplikacji, w którym klient zaczyna konfigurować formę płatności.
• Serwer Google: serwer backendu Google, który sprawdza uwierzytelnianie oraz inne zadania związane z uwierzytelnianiem.
• Plik APK integratora płatności: aplikacja integratora, w której użytkownik ma dostęp do swojego konta integratora.
• Serwer integratora płatności: serwer backendu integratora, na którym przechowywane są informacje o użytkowniku.

Jest to proces uwierzytelniania, więc zakładamy, że użytkownik używa aplikacji (interfejsu Google) i próbuje dodać formę płatności. To tutaj rozpoczyna się inicjowanie.

1. Interfejs użytkownika Google tworzy wywołanie uwierzytelniania, które jest wysyłane do serwera Google (backendu).
2. Serwer Google tworzy żądanie uwierzytelniania (AuthenticationRequest).
3. Serwer Google wysyła do interfejsu Google (aplikacji) pakiet APK wywołujący, żądając uwierzytelnienia.
4. Interfejs Google wysyła informacje o użytkowniku do pliku APK integratora płatności (AUTHENTICATE_V1(authReq)).
5. Plik APK integratora płatności wysyła żądanie (authReq) do serwera integratora płatności.
6. Serwer integratora płatności wysyła wyzwanie z powrotem do pliku APK integratora płatności.
7. Plik APK integratora płatności wysyła wyzwanie użytkownikowi.
8. Użytkownik dostarcza dowód tożsamości, który jest przesyłany do pliku APK integratora płatności.
9. Dane weryfikacyjne są przesyłane na serwer integratora płatności.
10. Serwer tworzy podpisany authenticationResponse.
11. Odpowiedź uwierzytelnienia się powiodła, a do pakietu APK integratora płatności wysyłany jest komunikat authResp.
12. Komunikat o powodzeniu (authResp) jest wysyłany z pakietu APK integratora płatności do interfejsu Google.
13. Interfejs Google wysyła odpowiedź do serwera Google.
14. Serwer Google interpretuje pomyślną odpowiedź.

Uwierzytelnianie SMS-MT za pomocą hasła jednorazowego

Inną metodą uwierzytelniania jest usługa krótkich wiadomości, przerwanie połączenia z urządzeniami mobilnymi, hasło jednorazowe (SMS-MT OTP). Ten mechanizm wykorzystuje numer telefonu użytkownika, aby wysłać mu jednorazowe hasło do uwierzytelnienia. Google prosi integratora o wysłanie hasła jednorazowego na numer telefonu użytkownika. Gdy użytkownik je otrzyma, a następnie wpisze je w interfejsie Google, zostanie on zweryfikowany.

Wykonaj te czynności:

1. Interfejs użytkownika (UI) Google prosi o podanie numeru telefonu, który jest już zarejestrowany w integratorze.
2. Użytkownik wpisuje numer telefonu w interfejsie Google.
3. Google aktywuje integratora (wywołujący metodę sendOtp), aby wysłać użytkownikowi hasło jednorazowe.
4. Użytkownik otrzymuje SMS-a z hasłem jednorazowym.
5. Następnie użytkownik wpisuje w interfejsie Google hasło jednorazowe (używane jako dane wejściowe w usługach capture, associateAccount i verifyOtp), aby uwierzytelnić użytkownika. Jest to dowód uwierzytelniania.

W trybie samodzielnym w celu weryfikacji wartości hasła jednorazowego wywoływana jest tylko metoda verifyOtp.

Ten schemat sekwencji przedstawia interakcję między telefonem użytkownika, Google i integratorem podczas wysyłania hasła jednorazowego:

Proces uwierzytelniania przez telefon (wysyłanie hasła jednorazowego)

Uwaga: powyższy diagram nie przedstawia użycia hasła jednorazowego jako danych wejściowych do innego wywołania. Te dane będą jednak używane jako dane wejściowe do różnych wywołań, np. verifyOtp i associateAccount.

Oto lista obiektów na diagramie i ich reprezentacji:

• Użytkownik: osoba, która chce dodać formę płatności do swojego konta Google.
• Interfejs Google: w tym przypadku jest to strona internetowa lub aplikacja na telefon Google, w której klient zaczyna konfigurować formę płatności. Uwaga: jeśli interfejs Google to aplikacja na telefon, pierwsze kilka kroków zostanie pominiętych, ponieważ telefon zna już numer telefonu użytkownika.
• Serwer Google: serwer backendu Google, który sprawdza uwierzytelnianie oraz inne zadania związane z uwierzytelnianiem.
• Serwer integratora płatności: serwer backendu integratora, na którym przechowywane są informacje o użytkowniku.

Ponieważ jest to proces uwierzytelniania za pomocą hasła jednorazowego, zakładamy, że użytkownik korzysta z aplikacji na telefon lub z witryny Google (interfejs Google) i próbuje dodać formę płatności. To tutaj rozpoczyna się inicjowanie.

1. Interfejs Google (telefon lub strona internetowa) poprosi użytkownika o podanie numeru telefonu.
2. Użytkownik wpisuje swój numer telefonu w interfejsie Google.
3. Interfejs Google wysyła numer (sendChallenge(phoneNum)) do serwera Google.
4. Serwer Google wysyła do serwera integratora płatności (SendOtp(phoneNum)) żądanie wysłania hasła jednorazowego.
5. Serwer integratora płatności wysyła do użytkownika hasło jednorazowe.
6. Serwer integratora płatności odpowiada na żądanie Google w punkcie 5, sygnalizując wysłanie hasła jednorazowego.
7. Użytkownik wpisuje hasło jednorazowe w interfejsie Google (na telefonie lub stronie internetowej).
8. Interfejs Google wysyła hasło jednorazowe na serwer Google, skąd jest następnie wysyłane do integratora płatności w celu weryfikacji. Pozwala to zweryfikować tożsamość użytkownika oraz go uwierzytelnić.

Uwierzytelnianie i ponowne uwierzytelnianie

Uwierzytelnianie może wystąpić w dwóch momentach:

1. Uwierzytelnianie wstępne – służy do identyfikowania i uwierzytelniania użytkowników. Wstępne uwierzytelnianie jest używane jako dane wejściowe w metodzie associateAccount.
2. Ponowne uwierzytelnianie – używane we wszystkich innych kontekstach, takich jak samodzielne lub jako dane wejściowe w capture.

Ponowne uwierzytelnianie różni się od uwierzytelniania wstępnego. Nie chce ponownie identyfikować użytkownika, a tylko ponownie się uwierzytelnić. Google używa ponownego uwierzytelnienia, aby umożliwić użytkownikowi udowodnienie, że jest właścicielem określonego konta. Dzieje się to według uznania Google.

W ramach tego procesu do pierwotnego powiązania (z poziomu procesu tworzenia powiązania) jest dostarczane odniesienie o nazwie associationId. Jest ona udostępniana przez wywołanie metody associateAccount podczas procesu powiązania. associationId identyfikuje konto, z którym ma zostać porównanie. Ze względów bezpieczeństwa użytkownik nie może zmienić konta, którego dotyczy test.

W przypadku ponownego uwierzytelniania SMS-MT za pomocą hasła jednorazowego Google przechowuje jako stały numer telefonu podany podczas pierwotnego połączenia z sendOtp. Dla bezpieczeństwa nie można tego zmienić.

Oto przykład procesu, w którym Google decyduje się na sprawdzenie tożsamości (ponowne uwierzytelnienie) przed zakupem:

Proces ponownego uwierzytelniania

Lista obiektów i ich reprezentacja wygląda tak:

• Użytkownik: jest to osoba, która chce dokonać zakupu.
• Interfejs Google: w tym przypadku jest to strona internetowa lub aplikacja na telefon Google, na której klient zaczyna dokonywać zakupu.
• Interfejs integratora płatności: witryna lub aplikacja dla klientów, w której użytkownik może uzyskać dostęp do informacji o koncie za pomocą integratora.
• Serwer Google: serwer backendu Google, który wykonuje sprawdzanie ponownego uwierzytelniania oraz inne zadania.
• Serwer integratora płatności: serwer backendu integratora, na którym przechowywane są informacje o użytkowniku.

Proces ponownego uwierzytelniania rozpoczyna się, gdy klient rozpoczyna zakup. Inicjuje to proces ponownego uwierzytelnienia użytkownika.

1. Użytkownik decyduje się na zakup produktu lub usługi.
2. Żądanie jest wysyłane z interfejsu Google do serwera Google.
3. Serwer Google odsyła do interfejsu Google żądanie uwierzytelnienia (authenticationRequest).
4. Interfejs Google wysyła do interfejsu integratora płatności żądanie uwierzytelnienia (associationId, authenticationRequest) tego użytkownika.
5. Interfejs integratora płatności wyszukuje użytkownika w celu zweryfikowania jego tożsamości (LookupIdentity(associationId)).
6. Interfejs integratora płatności prosi użytkownika o podanie danych logowania w swoim interfejsie (na stronie lub w aplikacji integratora).
7. Odpowiedź uwierzytelniająca jest wysyłana do serwera integratora płatności.
8. Podpisana odpowiedź uwierzytelniająca (authenticationResponse) jest odsyłana z powrotem do interfejsu integratora płatności.
9. Odpowiedź uwierzytelniająca (authenticationResponse) jest wysyłana z interfejsu integratora płatności do interfejsu Google.
10. Interfejs Google wysyła odpowiedź z informacjami o zakupie do serwera Google.
11. Serwer Google wysyła komunikat capture (aby znaleźć dostępne środki) na serwer integratora płatności (authenticationRequestId, GPT, kwota).
12. Serwer integratora płatności wysyła do serwera Google wiadomość o udanej transakcji.
13. Serwer Google wysyła do interfejsu Google komunikat o powodzeniu.
14. Interfejs Google dostarcza produkt(y) klientowi (lub powiadamia go, że wkrótce zostaną dostarczone).

Uwierzytelnianie SMS-MO

Usługa Short Message Service to proces uwierzytelniania opartego na danych mobilnych wykorzystujący SMS-a z identyfikatorem żądania uwierzytelniania wysłanego z telefonu użytkownika do integratora płatności w celu uwierzytelnienia użytkownika.

Oto lista obiektów na diagramie i ich reprezentacji:

• Użytkownik: osoba, która chce dodać formę płatności do swojego konta Google.
• Interfejs lub urządzenie Google: w tym przypadku aplikacja na telefon Google, w której klient zaczyna konfigurować formę płatności.
• Serwer Google: serwer backendu Google, który generuje instrukcje SMS z identyfikatorem żądania uwierzytelniania (ARID) i otrzymuje wynik uwierzytelniania od integratora.
• Serwer integratora płatności: serwer backendu integratora, który odbiera SMS-a uwierzytelniania i zwraca do Google identyfikator żądania uwierzytelniania.

Jest to proces uwierzytelniania, więc zakładamy, że użytkownik używa aplikacji (interfejsu Google) i próbuje dodać formę płatności. To tutaj rozpoczyna się inicjowanie.

1. Użytkownik wybiera tokenizowany instrument do dodania.
2. Interfejs Google wywołuje serwer Google, aby rozpocząć wyzwanie SMS-MO.
3. Serwer Google zwraca instrukcje SMS zawierające miejsce docelowe i treść zawierającą identyfikator żądania uwierzytelnienia.
4. Interfejs Google wysyła SMS-a do integratora płatności.
5. Serwer integratora płatności wywołuje punkt końcowy AuthenticatorResultResult na serwerze Google, podając identyfikator żądania uwierzytelniania.
6. Identyfikator żądania uwierzytelnienia jest weryfikowany przez serwer Google, co oznacza odpowiedź SUCCESS.
7. Interfejs Google wywołuje serwer Google, aby uzyskać wynik próby uwierzytelnienia.
8. Odpowiedź serwera Google POWIODŁA SIĘ.

Symulowane uwierzytelnianie SMS-MO

Na potrzeby testów diagnostycznych procesu uwierzytelniania SMS-MO Google definiuje punkt końcowy Simulation SMS. Dzięki temu nie trzeba wysyłać i weryfikować prawdziwego SMS-a podczas wykonywania powiązań testowych w środowisku piaskownicy.

Oto lista obiektów na diagramie i ich reprezentacji:

• Tester: osoba, która inicjuje test diagnostyczny powiązania SMS-MO.
• Interfejs Google: interfejs Google, w którym tester zaczyna i monitoruje stan testu diagnostycznego SMS-MO.
• Serwer Google: serwer backendu Google generuje instrukcje SMS z identyfikatorem żądania uwierzytelniania (ARID), wysyła symulowaną wiadomość SMS i otrzymuje wynik uwierzytelniania od integratora.
• Serwer integratora płatności: serwer backendu integratora, który odbiera symulowanego SMS-a uwierzytelniania i zwraca do Google identyfikator żądania uwierzytelniania.

W ramach tego procesu należy wykonać następujące kroki:

1. Tester rozpoczyna test diagnostyczny SMS-MO, podając identyfikator subskrybenta testu (SID), który jest używany do testu. Ten identyfikator SID zostanie dołączony do wywołania simulateSms integratora płatności.
2. Interfejs Google wywołuje serwer Google, aby rozpocząć wyzwanie SMS-MO.
3. Serwer Google zwraca instrukcje SMS zawierające miejsce docelowe i treść zawierającą identyfikator żądania uwierzytelnienia. Na potrzeby tego testu miejsce docelowe zostanie zastąpione przez połączenie HTTPS piaskownicy integratora płatności.
4. Interfejs Google wywołuje serwer Google, aby wysłać symulowanego SMS-a.
5. Wywołanie simulateSms jest przekazywane między serwerem Google a serwerem integratora płatności. Wywołanie interfejsu API obejmuje zarówno identyfikator żądania uwierzytelnienia, jak i identyfikator subskrybenta (jak podano w kroku 1).
6. Serwer integratora płatności odpowiada POTWIERDZONO.
7. Serwer Google odpowiada SUCCESS na komunikator Google.
8. Serwer integratora płatności wywołuje punkt końcowy AuthenticatorResultResult na serwerze Google, podając identyfikator żądania uwierzytelniania.
9. Serwer Google odpowiada SUCCESS.
10. Interfejs Google wywołuje serwer Google, aby uzyskać wynik próby uwierzytelnienia.
11. Serwer Google odpowiada COMPLETED (ukończono).
12. Interfejs Google wywołuje serwer Google, aby wykonać próbę powiązania.
13. Wywołanie associateAccount jest przekazywane między serwerem Google a serwerem integratora płatności.
14. Serwer integratora płatności odpowiada SUCCESS.
15. Serwer Google odpowiada SUCCESS.
16. Interfejs Google zostanie zaktualizowany, aby wskazać testerowi, że test diagnostyczny SMS-MO zakończył się powodzeniem.

Sprawdzone metody i inne kwestie

Wybór platform

Udostępnienie procesu uwierzytelniania w aplikacji mobilnej i na komputerze pozwoli integratorowi dotrzeć do największej liczby użytkowników. Google zdecydowanie zaleca integratorom obsługę aplikacji na Androida, ponieważ zapewnia ona użytkownikom maksymalną wygodę i osiąga najwyższy współczynnik konwersji. Parametry przekazywane w interfejsach API uwierzytelniania do aplikacji internetowych i na Androida są takie same.