Łączenie kont za pomocą protokołu OAuth i logowania przez Google (Dialogflow)

Typ połączenia OAuth i Logowanie przez Google dodaje Logowanie przez Google do technologii OAuth łączenie kont. Dzięki temu użytkownicy Google mogą bez trudu łączyć się za pomocą głosu. oraz umożliwić łączenie kont dla użytkowników, którzy zarejestrowali się w Twojej usłudze przy użyciu tożsamości innej niż Google.

Zaczyna się od Logowania przez Google, co pozwala sprawdzić, czy W Twoim systemie istnieją informacje z profilu Google. Jeśli dane użytkownika nieznajdujący się w systemie, rozpocznie się standardowy przepływ protokołu OAuth. Może też utworzyć nowe konto z informacjami z profilu Google.

Aby wykonać łączenie kont za pomocą protokołu OAuth i logowania przez Google, postępuj zgodnie z tymi ogólnymi wskazówkami kroki:

1. Najpierw poproś użytkownika o zgodę na dostęp do jego profilu Google.
2. Można go zidentyfikować na podstawie informacji podanych w jego profilu.
3. Jeśli nie możesz znaleźć dopasowania użytkownika Google w swoim systemie uwierzytelniania, proces przebiega w zależności od tego, czy Twój projekt Actions został skonfigurowany w Konsoli Actions, aby zezwolić na tworzenie kont użytkowników za pomocą głosu lub tylko do Twojej witryny.
   • Jeśli zezwalasz na tworzenie konta za pomocą głosu, zweryfikuj dokument tożsamości token otrzymany od Google. Następnie możesz utworzyć użytkownika na podstawie informacje o profilu zawarte w tokenie tożsamości.
   • Jeśli nie zezwolisz na tworzenie kont za pomocą głosu, użytkownik zostanie przeniesiony na w przeglądarce, w której można wczytać stronę autoryzacji i dokończyć proces proces tworzenia.

Pomoc w tworzeniu konta za pomocą głosu

Jeśli zezwolisz na tworzenie kont użytkowników za pomocą głosu, Asystent zapyta użytkownika, czy klient chce:

• Utwórz nowe konto w swoim systemie, korzystając z informacji o tym koncie Google.
• Zaloguj się do systemu uwierzytelniania przy użyciu innego konta, jeśli użytkownik ma istniejącego konta innego niż Google.

Jeśli chcesz zminimalizować ponieważ utrudniają proces tworzenia konta. Użytkownik musi tylko opuścić rozmowę głosową. aby zalogować się na istniejące konto spoza Google.

Nie zezwalaj na tworzenie konta za pomocą głosu

Jeśli nie zezwolisz na tworzenie kont użytkowników za pomocą głosu, Asystent otworzy adres URL, pod którym witryny podanej na potrzeby uwierzytelniania użytkowników. Jeśli interakcja ma miejsce na urządzeniu, które nie ma ekranu, Asystent skieruje użytkownika na telefon. aby kontynuować proces łączenia kont.

Nie zezwalaj na tworzenie, jeśli:

• Nie chcesz zezwalać użytkownikom, którzy mają konta spoza Google, na tworzenie konta użytkownika i chcesz, aby łączyły się one z dotychczasowymi kontami na Twoim uwierzytelniania. Jeśli na przykład oferujesz program lojalnościowy, warto się upewnić, że użytkownik nie traci punktów zgromadzonych na istniejącego konta.

• Musisz mieć pełną kontrolę nad procesem tworzenia konta. Możesz na przykład: nie zezwalaj na tworzenie, jeśli musisz pokazać użytkownikowi warunki korzystania z usługi w trakcie tworzenia konta.

Wdróż łączenie kont OAuth i Logowania przez Google

Konta są połączone ze standardowymi w branży procesami protokołu OAuth 2.0. Actions on Google obsługuje przepływy kodu niejawnego i kodu autoryzacji.

In the implicit code flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from the Assistant to your Action.

In the authorization code flow, you need two endpoints:

• The authorization endpoint, which is responsible for presenting the sign-in UI to your users that aren't already signed in and recording consent to the requested access in the form of a short-lived authorization code.
• The token exchange endpoint, which is responsible for two types of exchanges:
  1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
  2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.

Although the implicit code flow is simpler to implement, Google recommends that access tokens issued using the implicit flow never expire, because using token expiration with the implicit flow forces the user to link their account again. If you need token expiration for security reasons, you should strongly consider using the auth code flow instead.

Konfigurowanie projektu

Aby skonfigurować projekt do korzystania z protokołu OAuth i konta Logowania przez Google 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 Tak.

5. W sekcji Typ połączenia wybierz OAuth i Logowanie przez Google i Niejawne.

   

6. W sekcji Informacje o kliencie wykonaj te czynności:

   • Przypisz wartość do identyfikatora klienta wystawionego przez Twoje działania dla Google, aby zidentyfikować: pochodzących od Google.
   • Wstaw adresy URL punktów końcowych Authorization i Token Exchange.

7. Kliknij Zapisz.

Wdróż serwer OAuth

Aby obsługiwać niejawny przepływ OAuth 2.0, Twoja usługa wymaga autoryzacji punktu końcowego dostępnego przez HTTPS. Ten punkt końcowy odpowiada za uwierzytelnianie i uzyskiwania od użytkowników zgody na dostęp do danych. Punkt końcowy autoryzacji wyświetla interfejs logowania użytkownikom, którzy nie są jeszcze zalogowani, wyrazić zgodę na żądany dostęp.

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

Typowa sesja niejawnego przepływu zainicjowana przez Google w języku OAuth 2.0 ma następujący przepływ:

1. Google otworzy punkt końcowy autoryzacji w przeglądarce użytkownika. loguje się, jeśli jeszcze nie jest zalogowany, i zezwala Google na dostęp swoich danych za pomocą interfejsu API, jeśli nie udzielili jeszcze zgody.
2. Usługa tworzy token dostępu i zwraca go do Google przez przekierowanie przeglądarki użytkownika z powrotem do Google wraz z tokenem dostępu. do żądania.
3. Google wywołuje interfejsy API Twojej usługi i łączy token dostępu z każdego żądania. Usługa sprawdza, czy token dostępu przyznaje Google aby uzyskać dostęp do interfejsu API, a następnie wykonać jego wywołanie.

Obsługa żądań autoryzacji

Jeśli akcja musi połączyć konta przez niejawny przepływ OAuth2, Google wysyła użytkownika do punktu końcowego autoryzacji z żądaniem zawierającym ciąg 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&response_type=token

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

1. Sprawdź wartości client_id i redirect_uri w zapobiegaj przyznawaniu dostępu do niezamierzonych lub błędnie skonfigurowanych aplikacji klienckich:

   • Sprawdź, czy identyfikator client_id jest zgodny z Twoim identyfikatorem klienta przypisane do Google.
   • Sprawdź, czy URL podany w pliku redirect_uri ma taką postać:

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

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

2. Sprawdź, czy użytkownik jest zalogowany w Twojej usłudze. Jeśli użytkownik nie jest zalogowany dokończ proces logowania lub rejestracji w usłudze.

3. Wygeneruj token dostępu, którego Google będzie używać, aby uzyskiwać dostęp do Twojego interfejsu API. token dostępu może być dowolną wartością ciągu, ale musi jednoznacznie reprezentować i klienta, dla którego jest przeznaczony token, i nie może być odgadywany.

4. Wyślij odpowiedź HTTP przekierowującą przeglądarkę użytkownika na ten adres URL wskazywaną przez parametr redirect_uri. Uwzględnij wszystkie następujące parametry we fragmencie adresu URL:

   • access_token: wygenerowany właśnie przez Ciebie token dostępu.
   • token_type: ciąg znaków bearer
   • state: niezmodyfikowana wartość stanu pierwotnego, prośba Oto przykład powstałego adresu URL:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

Moduł obsługi przekierowań OAuth 2.0 od Google otrzyma token dostępu i potwierdzi że wartość state się nie zmieniła. Po uzyskaniu przez Google dla Twojej usługi, Google będzie dołączać ten token do kolejnych wywołań do akcji w ramach żądania AppRequest.

Obsługa automatycznego łączenia

Gdy użytkownik wyrazi zgodę na dostęp do profilu Google, Google wysyła żądanie zawierające podpisane potwierdzenie tożsamości użytkownika Google. Potwierdzenie zawiera informacje, które obejmują identyfikator konta Google użytkownika, jego nazwę i adres e-mail. Punkt końcowy wymiany tokenów skonfigurowany na potrzeby projektu obsługuje tę prośbę.

Jeśli w systemie uwierzytelniania już istnieje odpowiednie konto Google, punkt końcowy wymiany tokenów zwraca token użytkownika. Jeśli konto Google nie pasujące do istniejącego użytkownika, punkt końcowy wymiany tokenów zwraca błąd user_not_found.

Prośba ma taki format:

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

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=get&assertion=JWT&consent_code=CONSENT_CODE&scope=SCOPES

Punkt końcowy wymiany tokenów musi obsługiwać te parametry:

Gdy punkt końcowy wymiany tokenów otrzyma żądanie połączenia, powinien wykonać :

Weryfikowanie i dekodowanie potwierdzenia JWT

Potwierdzenie JWT możesz zweryfikować i zdekodować za pomocą biblioteki dekodowania JWT dla swojego języka. Użyj kluczy publicznych Google (dostępnych w językach JWK lub PEM), aby zweryfikować token podpis.

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": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}

Oprócz weryfikacji podpisu tokena sprawdź, czy wydawca potwierdzenia (pole iss) to https://accounts.google.com, a lista odbiorców (pole aud) to identyfikator klienta przypisany do Twojej akcji.

Sprawdź, czy konto Google znajduje się już w systemie uwierzytelniania

Sprawdź, czy spełniony jest jeden z tych warunków:

• Identyfikator konta Google znajdujący się w polu sub potwierdzenia znajduje się w bazie danych użytkowników.
• Adres e-mail podany w potwierdzeniu pasuje do użytkownika w bazie danych użytkowników.

Jeśli którykolwiek z tych warunków jest spełniony, użytkownik już się zarejestrował, więc możesz wysłać token dostępu.

Jeśli ani identyfikator konta Google, ani adres e-mail podany w potwierdzeniu pasuje do użytkownika w bazie danych, nie zarejestrował się jeszcze. W takim przypadku atrybut Punkt końcowy wymiany tokenów powinien odpowiedzieć z błędem HTTP 401, który określa error=user_not_found, Jak w tym przykładzie:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"user_not_found",
}

Handle account creation via Google Sign-In

When a user needs to create an account on your service, Google makes a request to your token exchange endpoint that specifies intent=create, as in the following example:

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

response_type=token&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&scope=SCOPES&intent=create&consent_code=CONSENT_CODE&assertion=JWT[&NEW_ACCOUNT_INFO]

The assertion parameter contains A JSON Web Token (JWT) that provides a signed assertion of the Google user's identity. The JWT contains information that includes the user's Google Account ID, name, and email address, which you can use to create a new account on your service.

To respond to account creation requests, your token exchange endpoint must do the following:

Weryfikowanie i dekodowanie potwierdzenia JWT

Potwierdzenie JWT możesz zweryfikować i zdekodować za pomocą biblioteki dekodowania JWT dla swojego języka. Użyj kluczy publicznych Google (dostępnych w językach JWK lub PEM), aby zweryfikować token podpis.

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": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}

Oprócz weryfikacji podpisu tokena sprawdź, czy wydawca potwierdzenia (pole iss) to https://accounts.google.com, a lista odbiorców (pole aud) to identyfikator klienta przypisany do Twojej akcji.

Validate user information and create new account

Check whether either of the following conditions are true:

• The Google Account ID, found in the assertion's sub field, is in your user database.
• The email address in the assertion matches a user in your user database.

If either condition is true, prompt the user to link their existing account with their Google Account by responding to the request with an HTTP 401 error, specifying error=linking_error and the user's email address as the login_hint, as in the following example:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}

If neither condition is true, create a new user account using the information provided in the JWT. New accounts do not typically have a password set. It is recommended that you add Google Sign In to other platforms to enable users to log in via Google across the surfaces of your application. Alternatively, you can email the user a link that starts your password recovery flow to allow the user to set a password for signing in on other platforms.

When the creation is completed, issue an access token and return the values in a JSON object in the body of your HTTPS response, like in the following example:

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

Rozpoczynanie procesu uwierzytelniania

Użyj intencji Asystenta logowania się na konto. aby rozpocząć proces uwierzytelniania.

const app = dialogflow({
  // REPLACE THE PLACEHOLDER WITH THE CLIENT_ID OF YOUR ACTIONS PROJECT
  clientId: CLIENT_ID,
})

// Intent that starts the account linking flow.
app.intent('Start Signin', conv => {
  conv.ask(new SignIn('To get your account details'))
})

private String clientId = "<your_client_id>";

@ForIntent("Start Signin")
public ActionResponse text(ActionRequest request) {
  ResponseBuilder rb = getResponseBuilder(request);
  return rb.add(new SignIn().setContext("To get your account details")).build();
}

const app = actionssdk({
  clientId: CLIENT_ID,
})

app.intent('Start Signin', conv => {
  conv.ask(new SignIn('To get your account details'))
})

private String clientId = "<your_client_id>";

@ForIntent("actions.intent.TEXT")
public ActionResponse text(ActionRequest request) {
  ResponseBuilder rb = getResponseBuilder(request);
  return rb.add(new SignIn().setContext("To get your account details")).build();
}

Obsługa żądań dostępu do danych

Jeśli prośba o Asystenta zawiera token dostępu, sprawdź najpierw, czy token dostępu jest prawidłowy i nie stracił ważności, a potem pobierz go ze swojego w bazie danych konta użytkownika, czyli konto użytkownika powiązane z tokenem.