Оптимальный тип привязки учетной записи для вашего действия — это тот, который обеспечивает максимально простой интерфейс для ваших пользователей и соответствует потребностям вашего приложения или бизнеса. Выбор типа ссылки в основном зависит от следующих факторов:
- Хотите ли вы разрешить создание учетной записи с помощью голоса
- Хотите ли вы, чтобы пользователи могли входить в ваш сервис с помощью учетной записи, отличной от Google?
- Может ли ваша служба хранить конфиденциальную информацию (например, секрет клиента)
Чтобы определить идеальный тип привязки учетной записи, выполните следующие действия:
- Рассмотрите вопросы в разделе «Определите предпочитаемый тип входа» .
- Обратитесь к дереву решений, чтобы выбрать тип ссылки.
- Перейдите к разделу, соответствующему выбранному вами исходному типу, чтобы уточнить принцип его работы.
Определите предпочитаемый тип входа
Прежде чем обращаться к дереву решений, рассмотрите следующие вопросы:
- Ожидаете ли вы, что у всех ваших пользователей будет учетная запись Google?
- Если ваше действие нацелено только на Ассистента, вы можете ожидать, что у всех ваших пользователей будет учетная запись Google. Если ваше действие ориентировано на платформы помимо Ассистента, вы не можете ожидать, что у всех ваших пользователей будет учетная запись Google.
- Если у вашей службы уже есть пользователи, вполне вероятно, что у некоторых из них нет учетной записи Google или они не вошли в вашу службу с помощью учетной записи Google.
- Если у вас есть реализация OAuth, можно ли ее расширить для поддержки протокола Google?
- Для поддержки протокола Google вам необходимо иметь возможность добавить функции
intent=getиintent=createв конечную точку обмена токенами. Эта функция позволяет Google проверить, существует ли пользователь уже в вашем бэкэнде, и соответственно сделать запрос на создание новой учетной записи в вашем сервисе.
- Для поддержки протокола Google вам необходимо иметь возможность добавить функции
Следуйте приведенному ниже дереву решений, чтобы определить тип привязки учетной записи, который оптимален для вас и ваших пользователей:
После того как вы выберете тип привязки, перейдите к соответствующему разделу ниже, чтобы узнать больше о том, как он работает, и принять дальнейшие решения о том, как привязка аккаунтов работает в вашем Действии.
«Упрощенное» связывание входа в Google на основе OAuth
Тип привязки «Оптимизированный» добавляет вход в Google (GSI) поверх привязки учетных записей на основе OAuth, что обеспечивает преимущества GSI (например, голосовое связывание для пользователей Google), а также позволяет привязывать учетные записи для пользователей, которые зарегистрировались в вашей учетной записи. сервис с учетной записью, отличной от Google. Этот тип ссылок особенно выгоден для конечных пользователей, поскольку он обеспечивает легкий поток для пользователей Google и запасной вариант для пользователей, не являющихся пользователями Google. Дополнительные сведения о том, как работает оптимизированное связывание, см. в руководстве по концепции «Оптимизированного» связывания для входа в Google на основе OAuth .
Уточните тип связи «Упрощенный» для входа в Google на основе OAuth.
Когда вы используете тип связи «Оптимизированный» в своем действии, вы указываете ответы на следующие вопросы в консоли «Действия», чтобы определить, как это работает:
Хотите ли вы включить создание голосовой учетной записи или разрешить создание учетной записи только на своем веб-сайте?
Как правило, вам следует включить создание учетной записи с помощью голоса, чтобы пользователи на неэкранированном устройстве могли создавать учетную запись без необходимости перехода на другое устройство. Если вы не разрешаете создание учетной записи с помощью голоса, Ассистент открывает URL-адрес веб-сайта, который вы указали для аутентификации пользователя, и направляет пользователя к телефону, чтобы продолжить процесс привязки учетной записи.
Однако вам не следует разрешать создание учетной записи с помощью голоса, если применимо любое из следующих условий:
- Вам необходим полный контроль над процессом создания учетной записи. Например, вам может потребоваться показать пользователю свои условия обслуживания во время создания учетной записи или уведомления другого типа.
- Вы хотите, чтобы пользователи, у которых уже есть учетная запись у вас, входили в систему с этой учетной записью. Например, вы можете захотеть, чтобы пользователи продолжали использовать свои существующие учетные записи, если вы предлагаете программу лояльности и не хотите, чтобы пользователь терял баллы, начисленные на его учетной записи.
Хотите ли вы использовать поток кода авторизации или неявный поток?
Поток кода авторизации и неявный поток отличаются тем, что для потока кода авторизации требуется вторая конечная точка — конечная точка обмена токенами . Эта конечная точка использует токены обновления для создания новых кратковременных токенов доступа без запроса пользователя на повторный вход.
И наоборот, если вы используете неявный поток, вы возвращаете в Google долгоживущий токен доступа, который обычно не требует повторной генерации. Дополнительные сведения о коде авторизации и неявных потоках см. в концептуальном руководстве по «упрощенному» связыванию входа в Google на основе OAuth .
Google рекомендует использовать поток кода авторизации в вашем действии, поскольку он более безопасен. Однако вместо этого используйте неявный поток , если ваша служба не может хранить конфиденциальную информацию (например, секрет клиента). Например, вы должны использовать неявный поток для общедоступных клиентов, таких как одностраничные приложения (SPA).
После рассмотрения этих точек принятия решений обратитесь к следующему дереву решений:
Вход в Google
При использовании типа привязки «Вход в Google» (GSI) ваше действие может запросить доступ к профилю Google вашего пользователя во время разговора и использовать информацию профиля, чтобы проверить, существует ли пользователь в серверной части вашей службы. Если пользователь не существует, он может создать новую учетную запись в вашей системе, используя информацию своего профиля Google.
Для GSI необходимо включить создание учетной записи с помощью голоса, что позволит пользователю выполнить весь процесс с помощью голоса. Дополнительную информацию о GSI см. в концептуальном руководстве по входу в Google .
OAuth-связывание
При использовании типа связи OAuth пользователь входит в систему, используя стандартный процесс OAuth 2.0. Тип связи OAuth поддерживает два стандартных потока OAuth 2.0: неявный поток и поток кода авторизации .
Google не рекомендует использовать тип связи OAuth сам по себе, поскольку он требует перевода пользователя с голоса на экран для завершения процесса входа, если пользователь находится на неэкранированном устройстве. Вы можете рассмотреть возможность использования этого процесса, если у вас есть существующая реализация сервера OAuth 2.0 и вы не можете расширить конечную точку обмена токенами, чтобы добавить поддержку протоколов Google для автоматического связывания и создания учетной записи из токена идентификатора. Дополнительную информацию см. в руководстве по концепции связывания OAuth .
Уточните поток
Когда вы используете тип связи OAuth в своем действии, вы должны указать ответ на следующий вопрос в консоли действий, чтобы определить, как это работает:
Хотите ли вы использовать поток кода авторизации или неявный поток?
Тип связи OAuth поддерживает два стандартных потока OAuth 2.0: неявный поток и поток кода авторизации . Поток кода авторизации и неявный поток отличаются тем, что для потока кода авторизации требуется вторая конечная точка — конечная точка обмена токенами . Эта конечная точка использует токены обновления для создания новых кратковременных токенов доступа без запроса пользователя на повторный вход.
И наоборот, если вы используете неявный поток, вы возвращаете в Google долгоживущий токен доступа, который обычно не требует повторной генерации. Дополнительные сведения о коде авторизации и неявных потоках см. в руководстве по концепции связывания OAuth .
Google рекомендует использовать поток кода авторизации в вашем действии, поскольку он более безопасен. Однако вместо этого используйте неявный поток , если ваша служба не может хранить конфиденциальную информацию (например, секрет клиента). Например, вы должны использовать неявный поток для общедоступных клиентов, таких как одностраничные приложения (SPA).