Обзор

Привязка учетных записей позволяет владельцам учетных записей Google быстро, легко и безопасно подключаться к вашим сервисам. Вы можете реализовать привязку учетной записи Google, чтобы делиться данными пользователя с вашей платформы с приложениями и службами Google.

Безопасный протокол OAuth 2.0 позволяет безопасно связать учетную запись Google пользователя с его учетной записью на вашей платформе, тем самым предоставляя приложениям и устройствам Google доступ к вашим сервисам.

Пользователи могут связывать или отключать свои учетные записи и при необходимости создавать новую учетную запись на вашей платформе с помощью функции «Привязка учетных записей Google».

Случаи использования

Некоторые из причин для реализации связывания учетных записей Google:

  • Делитесь данными пользователя со своей платформы с приложениями и сервисами Google.

  • Воспроизводите видео и фильмы с помощью Google TV .

  • Управляйте устройствами, подключенными к Google Smart Home, с помощью приложения Google Home и Google Assistant: «Эй, Google, включи свет».

  • Создавайте персонализированные для пользователя возможности и функции Google Ассистента с помощью диалоговых действий : «Эй, Google, закажи мой обычный товар в Starbucks».

  • Предоставьте пользователям возможность получать вознаграждения за просмотр подходящих прямых трансляций на YouTube после привязки своей учетной записи Google к учетной записи партнера по вознаграждениям .

  • Предварительно заполняйте новые учетные записи во время регистрации совместно используемыми данными из профиля учетной записи Google .

Поддерживаемые функции

Эти функции поддерживаются привязкой учетной записи Google:

  • Быстро и легко делитесь своими данными, используя неявный поток OAuth Linking .

  • Обеспечьте повышенную безопасность с помощью потока кода авторизации привязки OAuth .

  • Войдите в систему существующих пользователей или зарегистрируйте новых пользователей, проверенных Google, на своей платформе, получите их согласие и безопасно обменивайтесь данными с помощью Streamlined linking .

  • Уменьшите трение с помощью App Flip . В надежном приложении Google одним нажатием безопасно открывается проверенное приложение для Android или iOS, а одним нажатием предоставляется согласие пользователя и связываются учетные записи.

  • Повысьте конфиденциальность пользователей, определив настраиваемые области для обмена только необходимыми данными, повысьте доверие пользователей, четко определив, как используются их данные.

  • Доступ к данным и услугам, размещенным на вашей платформе, можно отозвать, отключив учетные записи. Внедрение дополнительной конечной точки отзыва токена позволяет вам синхронизироваться с событиями, инициируемыми Google, а защита между учетными записями (RISC) позволяет вам уведомлять Google о любых событиях отключения связи, которые происходят на вашей платформе.

Потоки связывания аккаунтов

Существует три процесса связывания учетных записей Google, каждый из которых основан на OAuth и требует от вас управления или контроля авторизации, соответствующей требованиям OAuth 2.0, и конечных точек обмена токенами.

В процессе связывания вы выдаете Google токены доступа для отдельных учетных записей Google после получения согласия владельцев учетных записей на связывание своих учетных записей и обмен данными.

Связывание OAuth («Веб-OAuth»)

Это базовый поток OAuth , который отправляет пользователей на ваш сайт для ссылки. Пользователь перенаправляется на ваш сайт для входа в свою учетную запись. После входа в систему пользователь соглашается на передачу своих данных в вашем сервисе Google. На этом этапе учетная запись Google пользователя и ваша служба связываются.

OAuth Linking поддерживает код авторизации и неявные потоки OAuth. В вашей службе должна быть размещена конечная точка авторизации, совместимая с OAuth 2.0, для неявного потока, а также должна быть предоставлена ​​конечная точка авторизации и обмена токенами при использовании потока кода авторизации.

Рисунок 1 . Привязка учетной записи на телефоне пользователя с помощью Web OAuth

Связывание App Flip на основе OAuth («App Flip»)

Поток OAuth, который отправляет пользователей в ваше приложение для связывания.

App Flip Linking на основе OAuth помогает пользователям перемещаться между вашими проверенными мобильными приложениями Android или iOS и платформой Google, чтобы просмотреть предлагаемые изменения доступа к данным и дать свое согласие на связывание их учетной записи на вашей платформе со своей учетной записью Google. Чтобы включить App Flip, ваша служба должна поддерживать связывание OAuth или связывание входа в Google на основе OAuth с использованием потока кода авторизации .

App Flip поддерживается как для Android , так и для iOS .

Как это работает:

Приложение Google проверяет, установлено ли ваше приложение на устройстве пользователя:

  • Если приложение найдено, пользователь «перебрасывается» на ваше приложение. Ваше приложение получает согласие пользователя на связывание учетной записи с Google, а затем «возвращается» на поверхность Google.
  • Если приложение не найдено или в процессе флип-связывания приложения возникает ошибка, пользователь перенаправляется в поток Streamlined или Web OAuth.

Фигура 2 . Привязка учетной записи на телефоне пользователя с помощью App Flip

Оптимизированное связывание на основе OAuth («Оптимизированное»)

Оптимизированное связывание входа в Google на основе OAuth добавляет вход в Google поверх связывания OAuth, позволяя пользователям завершить процесс связывания, не покидая поверхность Google, тем самым уменьшая трения и сбои. Оптимизированное связывание на основе OAuth обеспечивает удобство входа в систему, создания и связывания учетных записей за счет сочетания входа в Google и связывания по OAuth. Ваш сервис должен поддерживать авторизацию и конечные точки обмена токенами, совместимые с OAuth 2.0. Кроме того, ваша конечная точка обмена токенами должна поддерживать утверждения JSON Web Token (JWT) и реализовывать намерения check , create и get .

Как это работает:

Google подтверждает учетную запись пользователя и передает вам следующую информацию:

  • Если учетная запись пользователя существует в вашей базе данных, пользователь успешно связывает свою учетную запись Google со своей учетной записью в вашем сервисе.
  • Если в вашей базе данных для пользователя не существует учетной записи, пользователь может либо создать новую учетную запись 3P с заявленной информацией, которую предоставляет Google: адрес электронной почты, имя и изображение профиля , либо выбрать вход в систему и ссылку на другой адрес электронной почты (для этого потребуется для входа в ваш сервис через Web OAuth).

Рисунок 3 . Привязка учетной записи на телефоне пользователя с помощью Streamlined Linking

Какой поток следует использовать?

Мы рекомендуем реализовать все потоки, чтобы обеспечить пользователям максимальное удобство при связывании. Потоки переключения Streamlined и App уменьшают трудности при связывании, поскольку пользователи могут завершить процесс связывания за несколько шагов. Связывание Web OAuth требует наименьших усилий и является хорошей отправной точкой, после чего вы можете добавить другие потоки связывания.

Работа с токенами

Привязка учетных записей Google основана на отраслевом стандарте OAuth 2.0.

Вы выдаете токены доступа Google для отдельных учетных записей Google после получения согласия владельцев учетных записей на связывание своих учетных записей и обмен данными.

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

  • Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

  • Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

  • Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

  • You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
  • Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

  • Accept unexpired access tokens, even after a newer token is issued.
  • Use alternatives to Refresh Token Rotation.
  • Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

  • Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

  • Reduce the number of token requests during the maintenance period:

    • Limit maintenance periods to less than the access token lifetime.

    • Temporarily increase the access token lifetime:

      1. Increase token lifetime to greater than maintenance period.
      2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
      3. Enter maintenance.
      4. Respond to token requests with a 503 error code and empty body.
      5. Exit maintenance.
      6. Decrease token lifetime back to normal.

Регистрация в Google

Нам понадобятся сведения о вашей настройке OAuth 2.0 и предоставить учетные данные, чтобы включить привязку учетных записей. Подробности смотрите в регистрации .