Łączenie kont za pomocą protokołu OAuth

Typ połączenia OAuth obsługuje 2 standardowe przepływy kodu OAuth 2.0: przepływy niejawne i przepływy kodu autoryzacyjne.

W pośrednim przepływie kodu Google otwiera punkt końcowy autoryzacji w przeglądarce użytkownika. Po udanym logowaniu zwracasz token dostępu o długim czasie do Google. Ten token dostępu jest teraz dołączany do każdego żądania wysyłanego przez Asystenta do działania.

W ramach procesu kodu autoryzacji potrzebujesz 2 punktów końcowych:

• Punkt końcowy autoryzacji, który odpowiada za wyświetlanie interfejsu logowania użytkownikom, którzy nie są jeszcze zalogowani, i rejestrowanie zgody w żądanym terminie w postaci kodu o ograniczonym czasie ważności.
• Punkt końcowy giełdy tokenów odpowiedzialny za 2 typy giełd:
  1. Wymienia kod autoryzacji tokena długoterminowego i tokena dostępu o ograniczonym czasie ważności. Ta wymiana ma miejsce, gdy użytkownik przechodzi przez proces łączenia kont.
  2. Wymienia długotrwały token odświeżania na token dostępu o ograniczonym czasie ważności. Ta giełda ma miejsce, gdy Google potrzebuje nowego tokena dostępu, ponieważ wygasł.

Implementacja niejawnego przepływu kodu jest prostsza, ale Google zaleca, aby tokeny dostępu wydane z wykorzystaniem niejawnego przepływu nigdy nie wygasały, ponieważ korzystanie z tożsamości w wyniku takiego działania wymusza na użytkowniku ponowne połączenie konta. Jeśli ze względów bezpieczeństwa zależy Ci na wygaśnięciu tokena, rozważ użycie kodu uwierzytelniania.

Wdrażanie łączenia kont OAuth

Konfigurowanie projektu

Aby skonfigurować projekt do korzystania z połączenia OAuth, wykonaj te czynności:

1. Otwórz Konsolę Actions i wybierz projekt, którego chcesz użyć.
2. Kliknij kartę Programowanie i wybierz Łączenie kont.
3. Włącz przełącznik obok opcji Łączenie kont.
4. W sekcji Tworzenie konta wybierz Nie, chcę zezwolić na tworzenie konta tylko na mojej stronie internetowej.

5. W sekcji Typ połączenia wybierz Protokół OAuth i Kod autoryzacji.

   

6. W sekcji Informacje o kliencie:

   • Przypisz wartość do Identyfikatora klienta wydanego przez Actions to Google, aby identyfikować żądania pochodzące od Google.
   • Zwróć uwagę na wartość Identyfikator klienta wydany przez Google dla Twoich akcji.
   • Wstaw adresy URL punktów końcowych autoryzacji i Token Exchange.

6. Kliknij Zapisz.

Wdrażanie serwera OAuth

Implementacja przepływu kodu autoryzacji przez serwer OAuth 2.0 składa się z tych elementów: dwa punkty końcowe, które Twoja usługa udostępnia przez HTTPS. Pierwszy punkt końcowy to punkt końcowy autoryzacji, który odpowiada za znalezienie lub uzyskanie zgody użytkowników na dostęp do danych. Punkt końcowy autoryzacji wyświetla logowanie niezalogowani użytkownicy, którzy wyrażają zgodę na poproszono o dostęp. Drugi punkt końcowy to punkt końcowy wymiany tokenów, który jest służy do uzyskiwania zaszyfrowanych ciągów znaków zwanych tokenami, które autoryzują użytkownika działania aby uzyskać dostęp do usługi.

Gdy akcja musi wywołać jeden z interfejsów API Twojej usługi, Google używa tych punktów końcowych, aby uzyskać od użytkowników uprawnienia do wywoływania tych interfejsów w imieniu Google.

Sesja przepływu kodu autoryzacji OAuth 2.0 zainicjowana przez Google wygląda tak:

1. Google otworzy punkt końcowy autoryzacji w przeglądarce użytkownika. Jeśli przepływ na urządzeniu z włączonym głosem dla akcji, Google prześle na telefon.

2. Użytkownik loguje się (jeśli jeszcze nie jest zalogowany) i zezwala Google na uzyskać dostęp do swoich danych za pomocą Twojego interfejsu API, jeśli nie przyznał on jeszcze odpowiednich uprawnień.

3. Usługa tworzy kod autoryzacji i zwraca go do Google przez przekierowanie przeglądarki użytkownika z powrotem do Google z kodem autoryzacji; do żądania.

4. Google wysyła kod autoryzacji do punktu końcowego wymiany tokenów, który weryfikuje autentyczność kodu i zwraca token dostępu oraz token odświeżania. Token dostępu to token o ograniczonym czasie ważności, który jest blokowany to dane logowania umożliwiające dostęp do interfejsów API. Token odświeżania jest trwały który Google może przechowywać i wykorzystywać do pozyskiwania nowych tokenów dostępu, gdy tracą ważność.

5. Gdy użytkownik zakończy proces łączenia kont, każdy kolejny żądanie wysłane z Asystenta do webhooka realizacji zamówienia zawiera element token dostępu.

Obsługa żądań autoryzacji

Gdy akcja musi połączyć konta za pomocą kodu autoryzacji OAuth 2.0 Google wysyła użytkownika do punktu końcowego autoryzacji z żądaniem, które zawiera następujące parametry:

Jeśli na przykład punkt końcowy autoryzacji jest dostępny pod adresem https://myservice.example.com/auth, żądanie może wyglądać tak:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code

Aby punkt końcowy autoryzacji mógł obsługiwać żądania logowania, wykonaj te czynności:

1. Sprawdź, czy identyfikator client_id jest zgodny z identyfikatorem klienta Google użytym podczas rejestracji Google oraz że redirect_uri jest zgodny z przekierowaniem Google za Twoją usługę. Te kontrole są ważne, ponieważ uniemożliwiają przyznawanie dostępu niezamierzonych lub nieprawidłowo skonfigurowanych aplikacji klienckich.

   Jeśli obsługujesz wiele przepływów OAuth 2.0, sprawdź też, czy Obecny stan „response_type”: code.

2. Sprawdź, czy użytkownik jest zalogowany w Twojej usłudze. Jeśli użytkownik nie jest zalogowany, zalogować się w usłudze lub zarejestrować się w niej.

3. Wygeneruj kod autoryzacji, którego Google będzie używać do uzyskiwania dostępu do Twojego interfejsu API. Kod autoryzacji może być dowolnym ciągiem znaków, ale musi być unikalny reprezentuje użytkownika, klienta, dla którego jest przeznaczony token, i datę ważności kodu. i nie może być odgadywany. Zwykle zajmujesz się autoryzacją które wygasają po około 10 minutach.

4. Sprawdź, czy adres URL określony przez parametr redirect_uri ma taki format:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID

   YOUR_PROJECT_ID to identyfikator, który znajdziesz na stronie Ustawienia projektu w Konsoli Actions.

5. Przekieruj przeglądarkę użytkownika do adresu URL określonego w atrybucie redirect_uri. Dołącz kod autoryzacji właśnie wygenerowano oraz pierwotną, niezmodyfikowaną wartość stanu w przypadku przekierowania. , dołączając parametry code i state. Oto przykład. uzyskanego adresu URL:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Obsługa żądań wymiany tokenów

Punkt końcowy wymiany tokenów Twojej usługi odpowiada za 2 rodzaje tokenów giełdy:

• Wymiana kodów autoryzacji dla tokenów dostępu i tokenów odświeżania
• Wymiana tokenów odświeżania tokenów dostępu

Żądania wymiany tokenów zawierają te parametry:

Wymiana kodów autoryzacji dla tokenów dostępu i tokenów odświeżania

Gdy użytkownik się zaloguje, a punkt końcowy autoryzacji zwróci autoryzację krótkotrwałą do Google, wyślemy żądanie do punktu końcowego wymiany tokenów dla tokena dostępu i tokenu odświeżania.

W przypadku tych żądań wartość grant_type wynosi authorization_code, a wartość wynosi code to wartość kodu autoryzacji przydzielonego wcześniej firmie Google. Oto przykład żądania wymiany kodu autoryzacji dla token dostępu i token odświeżania:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Aby wymienić kody autoryzacji na token dostępu i token odświeżania, Punkt końcowy wymiany tokenów odpowiada na żądania POST wykonujące te kroki:

1. Sprawdź, czy client_id identyfikuje źródło żądania jako autoryzowane źródło. i że client_secret jest zgodna z oczekiwaną wartością.
2. Zweryfikuj te kwestie:
   • Kod autoryzacji jest prawidłowy i nie stracił ważności, a klient Identyfikator określony w żądaniu jest zgodny z identyfikatorem klienta powiązanym z kodu autoryzacji.
   • Adres URL określony przez parametr redirect_uri jest identyczny do wartości użytej we wstępnym żądaniu autoryzacji.
3. Jeśli nie możesz sprawdzić wszystkich powyższych kryteriów, zwróć żądanie HTTP Błąd 400 Nieprawidłowe żądanie z treścią {"error": "invalid_grant"}.
4. W przeciwnym razie wygeneruj odświeżenie, używając identyfikatora użytkownika z kodu autoryzacji. token i token dostępu. Tokeny te mogą mieć dowolną wartość w postaci ciągu znaków, ale muszą jednoznacznie reprezentuje użytkownika i klienta, dla którego jest przeznaczony token. Nie mogą być łatwe do odgadnięcia. W przypadku tokenów dostępu zanotuj też czas ważności tokena (zwykle godzinę po wydaniu tokena). Tokeny odświeżania nie wygasają.
5. Zwróć następujący obiekt JSON w treści odpowiedzi HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }
   

Google przechowuje token dostępu i token odświeżania użytkownika oraz rejestruje gdy upłynie okres ważności tokena dostępu. Gdy token dostępu wygaśnie, Google użyje odświeżenia , aby uzyskać nowy token dostępu z punktu końcowego wymiany tokenów.

Wymiana tokenów odświeżania tokenów dostępu

Gdy token dostępu wygaśnie, Google wysyła żądanie do punktu końcowego wymiany tokenów w celu wymiany tokena odświeżania na nowy token dostępu.

W przypadku tych żądań wartość grant_type wynosi refresh_token, a wartość refresh_token to wartość tokena odświeżania, który został przez Ciebie wcześniej przyznany Google. Poniżej znajdziesz przykład żądania wymiany tokena odświeżania dla token dostępu:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

Aby można było wymienić token odświeżania na token dostępu, punkt końcowy wymiany tokenów odpowiada na żądania (POST) wykonujące te czynności:

1. Sprawdź, czy client_id identyfikuje źródło żądania jako Google i że client_secret jest zgodny z oczekiwanym, .
2. Sprawdź, czy token odświeżania jest prawidłowy i czy identyfikator klienta określony w żądanie pasuje do identyfikatora klienta powiązanego z tokenem odświeżania.
3. Jeśli nie możesz sprawdzić wszystkich powyższych kryteriów, zwróć żądanie HTTP Błąd 400 Nieprawidłowe żądanie z treścią {"error": "invalid_grant"}.
4. W przeciwnym razie użyj identyfikatora użytkownika z tokena odświeżania, aby wygenerować dostęp token. Tokeny te mogą mieć dowolną wartość w postaci ciągu znaków, ale muszą jednoznacznie reprezentować użytkownika i klienta, dla których jest przeznaczony token. Nie mogą być one trudne do odgadnięcia. W przypadku tokenów dostępu zanotuj też czas ważności tokena (zwykle godzinę po wydaniu tokena).
5. Zwróć następujący obiekt JSON w treści protokołu HTTPS odpowiedź:

   {
   "token_type": "Nośnik",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   

Zaprojektuj interfejs głosowy pod kątem przepływu uwierzytelniania

Sprawdź, czy użytkownik został zweryfikowany, i rozpocznij proces łączenia kont

1. Otwórz projekt Actions Builder w Konsoli Actions.
2. Utwórz nową scenę, aby rozpocząć łączenie kont w Akcji:
   1. Kliknij Sceny.
   2. Aby dodać nową scenę, kliknij ikonę dodaj (+).
3. W nowo utworzonej scenie kliknij ikonę dodawania add w sekcji Warunki.
4. Dodaj warunek, który będzie sprawdzał, czy użytkownik powiązany z rozmową jest użytkownikiem zweryfikowanym. Jeśli sprawdzanie się nie powiedzie, akcja nie będzie mogła łączyć kont w trakcie rozmowy i powinna przyznać dostęp do funkcji, które nie wymagają łączenia kont.
   1. W polu Enter new expression w sekcji Warunek wpisz tę funkcję: user.verificationStatus != "VERIFIED"
   2. W sekcji Przejście wybierz scenę, która nie wymaga łączenia kont, ani scenę, która stanowi punkt wejścia do funkcji tylko dla gości.

1. Kliknij ikonę dodawania add obok pozycji Warunki.
2. Dodaj warunek aktywujący proces łączenia kont, jeśli użytkownik nie ma powiązanej tożsamości.
   1. W polu Enter new expression w sekcji Warunek wpisz tę funkcję: user.verificationStatus == "VERIFIED"
   2. W sekcji Przenoszenie wybierz scenę systemową Łączenie kont.
   3. Kliknij Zapisz.

Po zapisaniu do projektu zostanie dodana nowa scena systemu łączenia kont o nazwie <SceneName>_AccountLinking.

Dostosowywanie sceny łączenia kont

1. W sekcji Sceny wybierz scenę systemową łączenia kont.
2. Kliknij Wyślij prośbę i dodaj krótkie zdanie opisujące użytkownikowi, dlaczego akcja musi uzyskać dostęp do jego tożsamości (np. „Aby zapisać Twoje ustawienia”).
3. Kliknij Zapisz.

1. W sekcji Warunki kliknij Jeśli użytkownik ukończy łączenie kont.
2. Skonfiguruj sposób postępowania, jeśli użytkownik zgodzi się na połączenie swojego konta. Możesz na przykład wywołać webhooka, aby przetworzyć dowolną niezbędną niestandardową logikę biznesową i przejść z powrotem do sceny źródłowej.
3. Kliknij Zapisz.

1. W sekcji Warunki kliknij Jeśli użytkownik anuluje lub odrzuci łączenie kont.
2. Skonfiguruj sposób postępowania, jeśli użytkownik nie zgadza się na połączenie swojego konta. Możesz na przykład wysłać wiadomość z potwierdzeniem i przekierować użytkownika do scen, które udostępniają funkcje, które nie wymagają łączenia kont.
3. Kliknij Zapisz.

1. W sekcji Warunki kliknij W przypadku wystąpienia błędu systemu lub sieci.
2. Skonfiguruj proces, jeśli nie można go ukończyć z powodu błędów systemu lub sieci. Możesz na przykład wysłać wiadomość z potwierdzeniem i przekierować użytkownika do scen, które udostępniają funkcje, które nie wymagają łączenia kont.
3. Kliknij Zapisz.

Obsługiwanie próśb o dostęp do danych

Jeśli żądanie Asystenta zawiera token dostępu, najpierw sprawdź, czy token dostępu jest prawidłowy (i nie wygasł), a następnie pobierz powiązane konto użytkownika z bazy danych.