Optymalny typ połączenia kont dla akcji to najprostszy sposób łączenia kont użytkowników i spełniający potrzeby Twojej aplikacji lub firmy. Wybór typu połączenia zależy głównie od tych czynników:
- Określa, czy chcesz zezwolić na tworzenie kont za pomocą poleceń głosowych.
- to, czy użytkownicy mogą logować się w Twojej usłudze za pomocą konta innego niż konto Google.
- Określa, czy usługa może przechowywać informacje poufne (np.tajny klucz klienta).
Aby określić idealny typ połączenia kont:
- Odpowiedz na pytania w sekcji Określ preferowany typ logowania.
- Zapoznaj się z drzewem decyzyjnym, aby wybrać typ połączenia.
- Przejdź do sekcji odpowiadającej wybranemu typowi początkowemu, aby doprecyzować jego działanie.
Określanie preferowanego typu logowania
Zanim zapoznasz się z schematem decyzyjnym, zastanów się nad tymi kwestiami:
- Czy oczekujesz, że wszyscy użytkownicy będą mieli konta Google?
- Jeśli akcja jest kierowana tylko do Asystenta, możesz oczekiwać, że wszyscy użytkownicy mają konta Google. Jeśli akcja jest kierowana na platformy inne niż Asystent, nie możesz oczekiwać, że wszyscy użytkownicy będą mieli konta Google.
- Jeśli z Twojej usługi korzystają już obecni użytkownicy, prawdopodobnie niektórzy nie mają konta Google lub nie zalogowali się w niej za pomocą konta Google.
- Jeśli masz implementację OAuth, czy możesz ją rozszerzyć tak, aby obsługiwała protokół Google?
- Aby obsługiwać protokół Google, musisz mieć możliwość dodania funkcji
intent=getiintent=createdo punktu końcowego tokena wymiany tokenów. Ta funkcja pozwala Google sprawdzić, czy użytkownik istnieje już w backendie, i wysłać żądanie utworzenia nowego konta w Twojej usłudze.
- Aby obsługiwać protokół Google, musisz mieć możliwość dodania funkcji
Skorzystaj z poniższego schematu decyzyjnego, aby określić, który typ połączenia kont będzie najlepszy dla Ciebie i Twoich użytkowników:
Po wybraniu typu połączenia przejdź do odpowiedniej sekcji poniżej, aby dowiedzieć się więcej o tym, jak to działa, i podjąć dalsze decyzje dotyczące sposobu łączenia kont w akcji.
Ujednolicone łączenie funkcji Logowanie przez Google oparte na protokole OAuth
Uproszczony typ połączenia polega na dodaniu Logowania przez Google (GSI) do połączenia kont opartego na protokole OAuth, co daje korzyści GSI (na przykład łączenie głosowe dla użytkowników Google), a jednocześnie umożliwia łączenie kont użytkownikom, którzy zarejestrowali się w Twojej usłudze za pomocą konta innego niż Google. Ten typ połączenia jest szczególnie korzystny dla użytkowników, ponieważ umożliwia bezproblemowe przeprowadzenie konwersji przez użytkowników Google korzystających z usług innych niż Google. Więcej informacji o tym, jak działa uproszczone łączenie, znajdziesz w przewodniku po koncepcji uproszczonego łączenia Logowania przez OAuth.
Udoskonalenie typu połączenia „Ujednolicone” funkcji Logowanie przez Google oparte na protokole OAuth
Jeśli w akcji używasz ujednoliconego typu łączenia, możesz określić w Konsoli Actions odpowiedzi na te pytania, aby określić sposób działania:
Czy chcesz włączyć głosowe tworzenie konta, czy zezwolić tylko na tworzenie konta w witrynie?
Warto włączyć tworzenie kont za pomocą poleceń głosowych, aby użytkownicy, którzy nie wyświetlają ekranu, mogli utworzyć konto bez konieczności przenoszenia go na inne urządzenie. Jeśli nie zezwolisz na tworzenie kont za pomocą poleceń głosowych, Asystent otworzy adres URL strony internetowej podanej przez Ciebie w celu uwierzytelnienia użytkownika i przekieruje użytkownika na telefon, aby kontynuować proces łączenia kont.
Nie zezwalaj jednak na tworzenie kont za pomocą poleceń głosowych, jeśli ma miejsce jedna z tych sytuacji:
- Musisz mieć pełną kontrolę nad procesem tworzenia konta. Konieczne może być na przykład pokazanie użytkownikowi warunków korzystania z usługi podczas tworzenia konta lub innego rodzaju powiadomienia.
- Chcesz mieć pewność, że użytkownicy, którzy mają już Twoje konto, zalogują się na nie. Jeśli na przykład oferujesz program lojalnościowy i nie chcesz, aby użytkownicy stracili punkty zgromadzone na koncie, możesz chcieć, aby nadal mogli oni korzystać z dotychczasowych kont.
Czy chcesz użyć przepływu kodu autoryzacji czy przepływu niejawnego?
Przepływ kodu autoryzacji i przepływ niejawny różnią się tym, że przepływ kodu autoryzacji wymaga drugiego punktu końcowego – wymiany tokenów. Ten punkt końcowy używa tokenów odświeżania do generowania nowych, krótkotrwałych tokenów dostępu bez konieczności ponownego logowania się użytkownika.
I na odwrót: jeśli użyjesz przepływu domyślnego, zwracasz do Google długotrwały token dostępu, który zwykle nie wymaga ponownego generowania. Więcej informacji o kodzie autoryzacji i przepływach niejawnych znajdziesz w przewodniku po koncepcji łączenia ujednoliconego logowania Google opartego na protokole OAuth.
Zalecamy używanie w akcji przepływu kodu autoryzacji, ponieważ jest on bezpieczniejszy. Jeśli jednak Twoja usługa nie może przechowywać informacji poufnych (takich jak tajny klucz klienta), zastosuj przepływ niejawny. Na przykład w przypadku klientów publicznych, takich jak aplikacje jednostronicowe (SPA), należy użyć trybu niejawnego.
Po zapoznaniu się z tymi punktami decyzyjnymi zapoznaj się z tym schematem decyzyjnym:
Logowanie przez Google
Dzięki typowi połączenia Logowanie przez Google (GSI) akcja może prosić o dostęp do profilu Google użytkownika podczas rozmowy i używać informacji o profilu do sprawdzania, czy użytkownik istnieje w backendzie usługi. Jeśli użytkownik nie istnieje, może utworzyć nowe konto w Twoim systemie, korzystając ze swojego profilu Google.
W przypadku GSI musisz włączyć tworzenie kont za pomocą poleceń głosowych, co umożliwia użytkownikowi wykonywanie całej procedury za pomocą głosu. Więcej informacji o GSI znajdziesz w przewodniku po koncepcji logowania przez Google.
Łączenie przez OAuth
W przypadku typu połączenia OAuth użytkownik loguje się, korzystając ze standardowego procesu OAuth 2.0. Typ połączenia OAuth obsługuje 2 standardowe w branży przepływy OAuth 2.0: przepływ kodu implicit i autoryzacyjny.
Google nie zaleca korzystania z samego typu połączenia OAuth, ponieważ jeśli użytkownik korzysta z urządzenia, które nie podlega kontroli, w celu dokończenia procesu logowania trzeba przenieść użytkownika z głosu na ekran. Możesz skorzystać z tego procesu, jeśli masz już implementację serwera OAuth 2.0 i nie możesz rozszerzyć punktu końcowego wymiany tokenów, aby dodać obsługę protokołów Google do automatycznego łączenia i tworzenia kont z użyciem tokena identyfikatora. Więcej informacji znajdziesz w przewodniku po koncepcji łączenia protokołu OAuth.
Usprawnij przepływ
Jeśli w akcji używasz typu połączenia OAuth, musisz podać w konsoli Actions odpowiedź na to pytanie, aby określić sposób jej działania:
Czy chcesz użyć przepływu kodu autoryzacji czy przepływu niejawnego?
Typ połączenia OAuth obsługuje 2 standardowe w branży przepływy OAuth 2.0: przepływ kodu implicit i autoryzacyjny. Przepływ kodu autoryzacji i przepływ niejawny różnią się tym, że przepływ kodu autoryzacji wymaga drugiego punktu końcowego – punktu końcowego token Exchange. Ten punkt końcowy używa tokenów odświeżania do generowania nowych, krótkotrwałych tokenów dostępu bez konieczności ponownego logowania się użytkownika.
I na odwrót: jeśli użyjesz przepływu domyślnego, zwracasz do Google długotrwały token dostępu, który zwykle nie wymaga ponownego generowania. Więcej informacji o kodzie autoryzacji i procesach niejawnych znajdziesz w przewodniku po koncepcji łączenia protokołu OAuth.
Zalecamy używanie w akcji przepływu kodu autoryzacji, ponieważ jest on bezpieczniejszy. Jeśli jednak Twoja usługa nie może przechowywać informacji poufnych (takich jak tajny klucz klienta), zastosuj przepływ niejawny. Na przykład w przypadku klientów publicznych, takich jak aplikacje jednostronicowe (SPA), należy użyć trybu niejawnego.