Связывание учетной записи Google с OAuth (неявный поток — архив)

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

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

Привязка учетной записи Google: неявный поток OAuth.

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

Роли и обязанности

В таблице ниже определены роли и обязанности участников процесса неявной аутентификации OAuth через Google Account Linking (GAL). Обратите внимание, что в GAL Google выступает в роли клиента OAuth, а ваш сервис — в роли поставщика идентификации/услуг .

Типичная сессия неявного потока OAuth 2.0, инициированная Google, имеет следующий характер:

1. Google открывает вашу точку авторизации в браузере пользователя. Пользователь входит в систему, если он еще не вошел, и предоставляет Google разрешение на доступ к своим данным через ваш API, если он еще не предоставил такое разрешение.
2. Ваш сервис создает токен доступа и возвращает его в Google. Для этого перенаправьте браузер пользователя обратно на сайт Google, прикрепив токен доступа к запросу.
3. Google обращается к API вашего сервиса и прикрепляет токен доступа к каждому запросу. Ваш сервис проверяет, предоставляет ли токен доступа Google разрешение на доступ к API, а затем завершает вызов API.

Рецепт реализации

Выполните следующие шаги для реализации неявного потока.

Шаг 1: Обработка запросов на авторизацию

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

Для обработки запроса выполните следующие действия:

1. Подтвердите запрос :

   • Убедитесь, что client_id совпадает с идентификатором клиента, присвоенным Google.
   • Убедитесь, что redirect_uri соответствует ожидаемому URL-адресу перенаправления Google: none https://oauth-redirect.googleusercontent.com/r/YOUR_PARTNER_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PARTNER_ID
   • Убедитесь, что response_type имеет token .

2. Аутентификация пользователя :

   • Проверьте, вошел ли пользователь в вашу систему.
   • Если пользователь не авторизован, предложите ему пройти процедуру входа или регистрации.

3. Сгенерируйте токен доступа :

   • Создайте уникальный, не поддающийся угадыванию токен доступа, связанный с пользователем и клиентом.

4. Перенаправить обратно на Google :

   • Перенаправьте браузер на URL-адрес, указанный в redirect_uri .
   • Добавьте следующие параметры в фрагмент URL (хеш):
     • access_token : Сгенерированный вами токен доступа.
     • token_type : Должен быть bearer .
     • state : Неизмененное значение состояния, полученное от Google.

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.