Обзор

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

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

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

Варианты использования

Вот некоторые причины внедрения привязки аккаунта Google:

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

  • Воспроизводите видео- и киноконтент с помощью Google TV .

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

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

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

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

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

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

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

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

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

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

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

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

Потоки привязки аккаунтов

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

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

Связывание OAuth («Web OAuth»)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы рекомендуем реализовать все потоки, чтобы гарантировать пользователям наилучший опыт связывания. Потоки Streamlined и App Flip уменьшают трение связывания, поскольку пользователи могут завершить процесс связывания за очень мало шагов. Связывание 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 и данные для обмена учетными данными, чтобы включить привязку аккаунтов. Подробности см. в разделе «Регистрация» .