Связывание учетных записей позволяет владельцам учетных записей 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 .
Обеспечьте повышенную безопасность с помощью потока кода авторизации связывания OAuth .
Войдите в систему существующих пользователей или зарегистрируйте новых пользователей, проверенных Google, на своей платформе, получите их согласие и безопасно обменивайтесь данными с помощью упрощенного связывания .
Уменьшите трение с помощью App Flip . Из доверенного приложения Google одним нажатием можно безопасно открыть проверенное приложение для Android или iOS, а одним нажатием предоставить согласие пользователя и связать учетные записи.
Улучшите конфиденциальность пользователей, определив настраиваемые области для обмена только необходимыми данными, повысьте доверие пользователей, четко определив, как используются их данные.
Доступ к данным и службам, размещенным на вашей платформе, может быть отозван путем отключения учетных записей. Внедрение дополнительной конечной точки отзыва токена позволяет вам оставаться в курсе событий, инициированных Google, а защита между учетными записями (RISC) позволяет уведомлять Google о любых событиях отмены связи, происходящих на вашей платформе.
Потоки привязки аккаунта
Существует 3 потока привязки аккаунтов Google, каждый из которых основан на OAuth и требует, чтобы вы управляли или контролировали конечные точки авторизации и обмена токенами, совместимые с OAuth 2.0.
В процессе привязки вы выдаете токены доступа к Google для отдельных учетных записей Google после получения согласия владельцев учетных записей на привязку своих учетных записей и обмен данными.
Связывание OAuth («Веб-OAuth»)
Это основной поток OAuth , который отправляет пользователей на ваш сайт для ссылки. Пользователь перенаправляется на ваш сайт для входа в свою учетную запись. После входа в систему пользователь дает согласие на передачу своих данных в вашем сервисе Google. В этот момент учетная запись Google пользователя и ваша служба связаны.
Связывание OAuth поддерживает код авторизации и неявные потоки OAuth. Ваша служба должна размещать конечную точку авторизации, совместимую с OAuth 2.0, для неявного потока и должна предоставлять конечную точку авторизации и обмена токенами при использовании потока кода авторизации.

Рисунок 1 . Связывание учетной записи на телефоне пользователя с помощью Web OAuth
Связывание приложений на основе OAuth («App Flip»)
Поток OAuth, который отправляет пользователей в ваше приложение для связывания.
Связывание приложений на основе OAuth помогает пользователям перемещаться между вашими проверенными мобильными приложениями Android или iOS и платформой Google, чтобы просмотреть предлагаемые изменения доступа к данным и дать свое согласие на привязку своей учетной записи на вашей платформе к своей учетной записи Google. Чтобы включить App Flip, ваш сервис должен поддерживать связывание OAuth или связывание входа Google на основе OAuth с использованием потока кода авторизации .
Приложение Flip поддерживается как для Android , так и для iOS .
Как это работает:
Приложение Google проверяет, установлено ли ваше приложение на устройстве пользователя:
- Если приложение найдено, пользователь «переворачивается» на ваше приложение. Ваше приложение получает согласие пользователя на привязку учетной записи к Google, а затем «откатывается» на поверхность Google.
- Если приложение не найдено или возникает ошибка в процессе связывания приложения, пользователь перенаправляется на поток Streamlined или Web OAuth.

Рисунок 2 . Связывание учетной записи на телефоне пользователя с App Flip
Оптимизированное связывание на основе OAuth («Оптимизированное»)
Упрощенное связывание Google Sign-In на основе 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 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:
- Increase token lifetime to greater than maintenance period.
- Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
- Enter maintenance.
- Respond to token requests with a
503
error code and empty body. - Exit maintenance.
- Decrease token lifetime back to normal.
Регистрация в Google
Нам потребуются сведения о вашей настройке OAuth 2.0 и обмен учетными данными, чтобы разрешить привязку учетных записей. Подробности смотрите в регистрации .