Связывание учетных записей осуществляется с использованием стандартных для отрасли потоков неявной авторизации OAuth 2.0 и кодов авторизации .
Ваш сервис должен поддерживать авторизацию и конечные точки обмена токенами , соответствующие стандарту OAuth 2.0.
In the implicit 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 Google.
In the authorization code flow, you need two endpoints:
The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.
The token exchange endpoint, which is responsible for two types of exchanges:
- 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.
- 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.
Choose an OAuth 2.0 flow
Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.
Design guidelines
This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.
Requirements
- You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.
Recommendations
We recommend that you do the following:
Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.
Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.
Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.
Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.
Clear sign-in process. Ensure that users have clear method for signing in to their Google account, such as fields for their username and password or Sign in with Google.
Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.
Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.
- If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking and the implicit flow.
Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.
Создайте проект
Для создания проекта с использованием привязки учетных записей:
- Перейдите в консоль Google API .
- Нажмите «Создать проект» .
- Введите имя или примите предложенное имя.
- Подтвердите или отредактируйте оставшиеся поля.
- Нажмите «Создать» .
Чтобы просмотреть идентификатор вашего проекта:
- Go to the Google API Console .
- Найдите свой проект в таблице на главной странице. Идентификатор проекта указан в столбце ID .
Настройте экран согласия OAuth.
Процесс привязки учетной записи Google включает в себя экран согласия, который информирует пользователей о приложении, запрашивающем доступ к их данным, о типе запрашиваемых данных и применимых условиях. Вам потребуется настроить экран согласия OAuth перед генерацией идентификатора клиента Google API.
- Откройте страницу согласия OAuth в консоли Google API.
- Если появится запрос, выберите только что созданный вами проект.
На странице «Экран согласия OAuth» заполните форму и нажмите кнопку «Сохранить».
Название приложения: Название приложения, запрашивающего согласие. Название должно точно отражать ваше приложение и соответствовать названию приложения, которое пользователи видят в других местах. Название приложения будет отображаться на экране подтверждения привязки учетной записи.
Логотип приложения: изображение на экране согласия, которое поможет пользователям узнать ваше приложение. Логотип отображается на экране согласия при привязке учетной записи и в настройках учетной записи.
Адрес электронной почты службы поддержки: Для связи с пользователями по вопросам, касающимся их согласия.
Области действия для API Google: Области действия позволяют вашему приложению получать доступ к личным данным пользователей Google. Для сценария использования привязки учетной записи Google достаточно области действия по умолчанию (электронная почта, профиль, OpenID), добавлять какие-либо конфиденциальные области действия не требуется. Как правило, рекомендуется запрашивать области действия постепенно, по мере необходимости доступа, а не сразу. Подробнее .
Авторизованные домены: Для вашей защиты и защиты ваших пользователей Google разрешает использовать авторизованные домены только приложениям, аутентифицирующимся с помощью OAuth. Ссылки на ваши приложения должны размещаться на авторизованных доменах. Подробнее .
Ссылка на главную страницу приложения: Домашняя страница вашего приложения. Должна размещаться на авторизованном домене.
Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.
Ссылка на Условия использования приложения (необязательно): Приложение должно размещаться на авторизованном домене.

Рисунок 1. Экран согласия на привязку учетной записи Google для вымышленного приложения Tunery.
Проверьте «Статус проверки». Если ваше приложение нуждается в проверке, нажмите кнопку «Отправить на проверку», чтобы отправить приложение на проверку. Подробную информацию см. в требованиях к проверке OAuth .
Реализуйте свой OAuth-сервер.
н
Для поддержки неявного потока OAuth 2.0 ваш сервис предоставляет конечную точку авторизации по протоколу HTTPS. Эта конечная точка отвечает за аутентификацию и получение согласия пользователей на доступ к данным. Конечная точка авторизации отображает пользователям, которые еще не авторизованы, интерфейс входа в систему и регистрирует согласие на запрошенный доступ.
Когда приложению Google необходимо вызвать один из авторизованных API вашего сервиса, Google использует эту конечную точку, чтобы получить разрешение от ваших пользователей на вызов этих API от их имени.
Типичная сессия неявного потока OAuth 2.0, инициированная Google, имеет следующий характер:
- Google открывает вашу точку авторизации в браузере пользователя. Пользователь входит в систему, если он еще не вошел, и предоставляет Google разрешение на доступ к своим данным через ваш API, если он еще не предоставил такое разрешение.
- Your service creates an access token and returns it to Google. To do so, redirect the user's browser back to Google with the access token attached to the request.
- Google обращается к API вашего сервиса и прикрепляет токен доступа к каждому запросу. Ваш сервис проверяет, предоставляет ли токен доступа Google разрешение на доступ к API, а затем завершает вызов API.
Обработка запросов на авторизацию
Когда приложению Google необходимо выполнить привязку учетной записи через неявный поток OAuth 2.0, Google направляет пользователя на вашу конечную точку авторизации с запросом, содержащим следующие параметры:
| Параметры конечной точки авторизации | |
|---|---|
client_id | Идентификатор клиента, который вы присвоили Google. |
redirect_uri | URL-адрес, на который вы отправляете ответ на этот запрос. |
state | Бухгалтерское значение, которое передается обратно в Google в неизмененном виде в URI перенаправления. |
response_type | Тип возвращаемого значения в ответе. Для неявного потока OAuth 2.0 тип ответа всегда равен token . |
user_locale | Языковые настройки учетной записи Google в формате RFC5646 используются для локализации контента на предпочитаемый пользователем язык. |
Например, если ваша точка авторизации доступна по адресу https://myservice.example.com/auth , запрос может выглядеть следующим образом:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE
Для обработки запросов на вход в систему через точку авторизации выполните следующие действия:
Проверьте значения
client_idиredirect_uri, чтобы предотвратить предоставление доступа непредусмотренным или неправильно настроенным клиентским приложениям:- Убедитесь, что
client_idсовпадает с идентификатором клиента, который вы присвоили Google. - Убедитесь, что URL-адрес, указанный параметром
redirect_uri, имеет следующий вид:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Убедитесь, что
Проверьте, вошел ли пользователь в вашу систему. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей системе.
Сгенерируйте токен доступа для Google, который будет использоваться для доступа к вашему API. Токен доступа может быть любым строковым значением, но он должен однозначно представлять пользователя и клиент, для которого предназначен токен, и не должен быть угадываемым.
Отправьте HTTP-ответ, который перенаправит браузер пользователя на URL-адрес, указанный параметром
redirect_uri. Включите все следующие параметры в фрагмент URL-адреса:-
access_token: Токен доступа, который вы только что сгенерировали. -
token_type: Строковыйbearer -
state: Неизмененное значение состояния из исходного запроса.
Ниже приведён пример результирующего URL-адреса:
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
-
Обработчик перенаправлений OAuth 2.0 от Google получает токен доступа и подтверждает, что значение state не изменилось. После получения токена доступа к вашему сервису Google прикрепляет этот токен к последующим вызовам API вашего сервиса.
处理 userinfo 请求
userinfo 端点是受 OAuth 2.0 保护的资源,会返回关联用户的声明。实现和托管 userinfo 端点是可选的,但以下用例除外:
从您的令牌端点成功检索到访问令牌后,Google 会向您的 userinfo 端点发送请求,以检索关联用户的基本个人资料信息。
| userinfo 端点请求标头 | |
|---|---|
Authorization header |
Bearer 类型的访问令牌。 |
例如,如果您的 userinfo 端点可通过
https://myservice.example.com/userinfo 时,请求可能如下所示:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
为了让 userinfo 端点能够处理请求,请执行以下步骤:
- 从 Authorization 标头中提取访问令牌,并返回与访问令牌相关联的用户的信息。
- 如果访问令牌无效,则使用
WWW-Authenticate响应标头返回 HTTP 401 Unauthorized 错误。下面是一个 userinfo 错误响应示例: 如果在关联过程中返回 401 未经授权错误或任何其他失败的错误响应,该错误将无法恢复,检索到的令牌将被舍弃,并且用户必须重新开始关联流程。HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
如果访问令牌有效,则返回 HTTPS 正文中包含以下 JSON 对象的 HTTP 200 响应 回答:
如果您的 userinfo 端点返回 HTTP 200 成功响应,则系统会针对用户的 Google 账号注册检索到的令牌和声明。{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }userinfo 端点响应 sub系统中用于识别用户的唯一 ID。 email用户的电子邮件地址。 given_name可选:用户的名字。 family_name可选:用户的姓氏。 name可选:用户的全名。 picture可选:用户的个人资料照片。
Проверка вашей реализации
Вы можете проверить свою реализацию, используя инструмент OAuth 2.0 Playground .
В инструменте выполните следующие действия:
- Нажмите конфигурации », чтобы открыть окно «Конфигурация OAuth 2.0».
- В поле «Процесс аутентификации OAuth» выберите «На стороне клиента» .
- В поле «Конечные точки OAuth» выберите «Пользовательские» .
- Укажите в соответствующих полях вашу конечную точку OAuth 2.0 и идентификатор клиента, который вы присвоили Google.
- В разделе «Шаг 1» не выбирайте никаких областей действия Google. Вместо этого оставьте это поле пустым или введите область действия, действительную для вашего сервера (или произвольную строку, если вы не используете области действия OAuth). После завершения нажмите «Авторизовать API» .
- В разделах «Шаг 2» и «Шаг 3» пройдите весь процесс аутентификации OAuth 2.0 и убедитесь, что каждый шаг работает должным образом.
Вы можете проверить работоспособность своей реализации, используя демонстрационный инструмент для привязки учетных записей Google .
В инструменте выполните следующие действия:
- Нажмите кнопку « Войти через Google» .
- Выберите учетную запись, которую хотите связать.
- Введите идентификатор службы.
- При желании укажите одну или несколько областей доступа, к которым вы запрашиваете доступ.
- Нажмите «Начать демонстрацию» .
- При появлении запроса подтвердите свое согласие и отклоните запрос на привязку.
- Убедитесь, что вас перенаправили на вашу платформу.