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.
OAuth i Logowanie przez Google
Połączenie OAuth i Google Sign-In (GSI) wzbogaca połączenie kont oparte na protokole OAuth, co ma zalety GSI (na przykład połą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 przy użyciu 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łają połączenia OAuth i GSI, znajdziesz w przewodniku po koncepcji protokołu OAuth i logowania przez Google.
Sprecyzuj typ połączenia OAuth i Logowania przez Google
Jeśli w akcji używasz typu łączenia kont OAuth i GSI, określasz w Konsoli Actions odpowiedzi na te pytania:
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 podanej 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 protokołu OAuth i logowania przez Google.
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 GSI akcja może prosić o dostęp do profilu Google użytkownika podczas rozmowy i używać informacji z 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.
OAuth
W przypadku typu połączenia OAuth użytkownik loguje się za pomocą standardowego procesu OAuth 2. 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 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 protokołu OAuth.
Usprawnij przepływ
Jeśli w swojej akcji używasz typu łączenia konta 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 przepływach niejawnych znajdziesz w przewodniku po koncepcji 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.