Связывание аккаунта Google с OAuth

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

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

В потоке кода авторизации вам нужны две конечные точки:

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

• Конечная точка обмена токенами , которая отвечает за два типа обмена:

  1. Заменяет код авторизации на долгосрочный токен обновления и кратковременный токен доступа. Этот обмен происходит, когда пользователь проходит процедуру привязки учетной записи.
  2. Заменяет долгосрочный токен обновления на кратковременный токен доступа. Этот обмен происходит, когда Google нужен новый токен доступа, поскольку срок действия того, у которого истек срок действия.

Выберите поток OAuth 2.0.

Хотя неявный поток проще реализовать, Google рекомендует, чтобы токены доступа, выданные неявным потоком, никогда не истекали. Это связано с тем, что пользователь вынужден снова связать свою учетную запись после истечения срока действия токена с неявным потоком. Если вам необходим срок действия токена по соображениям безопасности, мы настоятельно рекомендуем вместо этого использовать поток кода авторизации .

Рекомендации по проектированию

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

Требования

1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.

Рекомендации

Мы рекомендуем вам сделать следующее:

1. Отобразите Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

2. Данные для обмена. Используйте ясный и краткий язык, чтобы сообщить пользователю, какие данные требуются Google и почему.

3. Четкий призыв к действию. Укажите четкий призыв к действию на экране согласия, например «Согласитесь и разместите ссылку». Это связано с тем, что пользователям необходимо понимать, какими данными они должны поделиться с Google, чтобы связать свои учетные записи.

4. Возможность отмены. Предоставьте пользователям возможность вернуться или отменить ссылку, если они решат не устанавливать ссылку.

5. Очистить процесс входа. Убедитесь, что у пользователей есть понятный способ входа в свою учетную запись Google, например поля для имени пользователя и пароля или «Войти через Google» .

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

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

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

8. Включите свой логотип. Отобразите логотип вашей компании на экране согласия. Используйте свои рекомендации по стилю для размещения логотипа. Если вы хотите также отображать логотип Google, см. раздел Логотипы и товарные знаки .

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

В потоке кода авторизации вам нужны две конечные точки:

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

• Конечная точка обмена токенами , которая отвечает за два типа обмена:

  1. Заменяет код авторизации на долгосрочный токен обновления и кратковременный токен доступа. Этот обмен происходит, когда пользователь проходит процедуру привязки учетной записи.
  2. Заменяет долгосрочный токен обновления на кратковременный токен доступа. Этот обмен происходит, когда Google нужен новый токен доступа, поскольку срок действия того, у которого истек срок действия.

Выберите поток OAuth 2.0.

Хотя неявный поток проще реализовать, Google рекомендует, чтобы токены доступа, выданные неявным потоком, никогда не истекали. Это связано с тем, что пользователь вынужден снова связать свою учетную запись после истечения срока действия токена с неявным потоком. Если вам необходим срок действия токена по соображениям безопасности, мы настоятельно рекомендуем вместо этого использовать поток кода авторизации .

Рекомендации по проектированию

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

Требования

1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.

Рекомендации

Мы рекомендуем вам сделать следующее:

1. Отобразите Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

2. Данные для обмена. Используйте ясный и краткий язык, чтобы сообщить пользователю, какие данные требуются Google и почему.

3. Четкий призыв к действию. Укажите четкий призыв к действию на экране согласия, например «Согласитесь и разместите ссылку». Это связано с тем, что пользователям необходимо понимать, какими данными они должны поделиться с Google, чтобы связать свои учетные записи.

4. Возможность отмены. Предоставьте пользователям возможность вернуться или отменить ссылку, если они решат не устанавливать ссылку.

5. Очистить процесс входа. Убедитесь, что у пользователей есть понятный способ входа в свою учетную запись Google, например поля для имени пользователя и пароля или «Войти через Google» .

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

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

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

8. Включите свой логотип. Отобразите логотип вашей компании на экране согласия. Используйте свои рекомендации по стилю для размещения логотипа. Если вы хотите также отображать логотип Google, см. раздел Логотипы и товарные знаки .

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

В потоке кода авторизации вам нужны две конечные точки:

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

• Конечная точка обмена токенами , которая отвечает за два типа обмена:

  1. Заменяет код авторизации на долгосрочный токен обновления и кратковременный токен доступа. Этот обмен происходит, когда пользователь проходит процедуру привязки учетной записи.
  2. Заменяет долгосрочный токен обновления на кратковременный токен доступа. Этот обмен происходит, когда Google нужен новый токен доступа, поскольку срок действия того, у которого истек срок действия.

Выберите поток OAuth 2.0.

Хотя неявный поток проще реализовать, Google рекомендует, чтобы токены доступа, выданные неявным потоком, никогда не истекали. Это связано с тем, что пользователь вынужден снова связать свою учетную запись после истечения срока действия токена с неявным потоком. Если вам необходим срок действия токена по соображениям безопасности, мы настоятельно рекомендуем вместо этого использовать поток кода авторизации .

Рекомендации по проектированию

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

Требования

1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.

Рекомендации

Мы рекомендуем вам сделать следующее:

1. Отобразите Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

2. Данные для обмена. Используйте ясный и краткий язык, чтобы сообщить пользователю, какие данные требуются Google и почему.

3. Четкий призыв к действию. Укажите четкий призыв к действию на экране согласия, например «Согласитесь и разместите ссылку». Это связано с тем, что пользователям необходимо понимать, какими данными они должны поделиться с Google, чтобы связать свои учетные записи.

4. Возможность отмены. Предоставьте пользователям возможность вернуться или отменить ссылку, если они решат не устанавливать ссылку.

5. Очистить процесс входа. Убедитесь, что у пользователей есть понятный способ входа в свою учетную запись Google, например поля для имени пользователя и пароля или «Войти через Google» .

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

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

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

8. Включите свой логотип. Отобразите логотип вашей компании на экране согласия. Используйте свои рекомендации по стилю для размещения логотипа. Если вы хотите также отображать логотип Google, см. раздел Логотипы и товарные знаки .

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

В потоке кода авторизации вам нужны две конечные точки:

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

• Конечная точка обмена токенами , которая отвечает за два типа обмена:

  1. Заменяет код авторизации на долгосрочный токен обновления и кратковременный токен доступа. Этот обмен происходит, когда пользователь проходит процедуру привязки учетной записи.
  2. Заменяет долгосрочный токен обновления на кратковременный токен доступа. Этот обмен происходит, когда Google нужен новый токен доступа, поскольку срок действия того, у которого истек срок действия.

Выберите поток OAuth 2.0.

Хотя неявный поток проще реализовать, Google рекомендует, чтобы токены доступа, выданные неявным потоком, никогда не истекали. Это связано с тем, что пользователь вынужден снова связать свою учетную запись после истечения срока действия токена с неявным потоком. Если вам необходим срок действия токена по соображениям безопасности, мы настоятельно рекомендуем вместо этого использовать поток кода авторизации .

Рекомендации по проектированию

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

Требования

1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.

Рекомендации

Мы рекомендуем вам сделать следующее:

1. Отобразите Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

2. Данные для обмена. Используйте ясный и краткий язык, чтобы сообщить пользователю, какие данные требуются Google и почему.

3. Четкий призыв к действию. Укажите четкий призыв к действию на экране согласия, например «Согласитесь и разместите ссылку». Это связано с тем, что пользователям необходимо понимать, какими данными они должны поделиться с Google, чтобы связать свои учетные записи.

4. Возможность отмены. Предоставьте пользователям возможность вернуться или отменить ссылку, если они решат не устанавливать ссылку.

5. Очистить процесс входа. Убедитесь, что у пользователей есть понятный способ входа в свою учетную запись Google, например поля для имени пользователя и пароля или «Войти через Google» .

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

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

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

8. Включите свой логотип. Отобразите логотип вашей компании на экране согласия. Используйте свои рекомендации по стилю для размещения логотипа. Если вы хотите также отображать логотип Google, см. раздел Логотипы и товарные знаки .

Создайте проект

Для создания проекта с использованием привязки учетных записей:

1. Перейдите в консоль Google API .
2. Нажмите «Создать проект» .
3. Введите имя или примите предложенное имя.
4. Подтвердите или отредактируйте оставшиеся поля.
5. Нажмите «Создать» .

Чтобы просмотреть идентификатор вашего проекта:

1. Go to the Google API Console .
2. Найдите свой проект в таблице на главной странице. Идентификатор проекта указан в столбце ID .

Настройте экран согласия OAuth.

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

1. Откройте страницу согласия OAuth в консоли Google API.
2. Если появится запрос, выберите только что созданный вами проект.

3. На странице «Экран согласия 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.

4. Проверьте «Статус проверки». Если ваше приложение нуждается в проверке, нажмите кнопку «Отправить на проверку», чтобы отправить приложение на проверку. Подробную информацию см. в требованиях к проверке OAuth .

Реализуйте свой OAuth-сервер.

Реализация потока авторизационного кода на сервере OAuth 2.0 состоит из двух конечных точек, которые ваш сервис предоставляет по протоколу HTTPS. Первая конечная точка — это точка авторизации, которая отвечает за поиск или получение согласия пользователей на доступ к данным. Точка авторизации отображает пользовательский интерфейс входа в систему для пользователей, которые еще не авторизованы, и регистрирует согласие на запрошенный доступ. Вторая конечная точка — это точка обмена токенами, которая используется для получения зашифрованных строк, называемых токенами, которые авторизуют пользователя для доступа к вашему сервису.

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

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

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

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

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

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

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

Обработка запросов на авторизацию

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

Например, если ваша точка авторизации доступна по адресу https://myservice.example.com/auth , запрос может выглядеть следующим образом:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

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

1. Убедитесь, что client_id совпадает с идентификатором клиента, который вы присвоили Google, и что redirect_uri совпадает с URL-адресом перенаправления, предоставленным Google для вашего сервиса. Эти проверки важны для предотвращения предоставления доступа непредусмотренным или неправильно настроенным клиентским приложениям. Если вы поддерживаете несколько потоков OAuth 2.0, также убедитесь, что response_type имеет значение code .
2. Проверьте, вошел ли пользователь в вашу систему. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей системе.
3. Сгенерируйте код авторизации для Google, который будет использоваться для доступа к вашему API. Код авторизации может быть любым строковым значением, но он должен однозначно представлять пользователя, клиента, для которого предназначен токен, и время истечения срока действия кода, и его нельзя угадать. Обычно выдаются коды авторизации, срок действия которых истекает примерно через 10 минут.
4. Убедитесь, что URL-адрес, указанный параметром redirect_uri , имеет следующий вид:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. Перенаправьте браузер пользователя на URL-адрес, указанный параметром redirect_uri . При перенаправлении добавьте к параметрам code и state сгенерированный вами код авторизации и исходное, неизмененное значение состояния. Ниже приведен пример результирующего URL-адреса:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Обработка запросов на обмен токенов

Конечная точка обмена токенов вашего сервиса отвечает за два типа обмена токенов:

• Обменивайте коды авторизации на токены доступа и токены обновления.
• Обменяйте токены обновления на токены доступа.

Запросы на обмен токенов включают следующие параметры:

Обменивайте коды авторизации на токены доступа и токены обновления.

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

Для таких запросов значение параметра grant_type равно authorization_code , а значение параметра code — это значение кода авторизации, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен кода авторизации на токен доступа и токен обновления:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Для обмена кодов авторизации на токен доступа и токен обновления ваша конечная точка обмена токенов отвечает на POST запросы, выполняя следующие действия:

1. Убедитесь, что client_id идентифицирует источник запроса как авторизованный, и что client_secret соответствует ожидаемому значению.
2. Убедитесь, что код авторизации действителен и не просрочен, а также что идентификатор клиента, указанный в запросе, совпадает с идентификатором клиента, связанным с кодом авторизации.
3. Убедитесь, что URL-адрес, указанный параметром redirect_uri , идентичен значению, использованному в первоначальном запросе на авторизацию.
4. Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с телом запроса {"error": "invalid_grant"} .
5. В противном случае используйте идентификатор пользователя из кода авторизации для генерации токена обновления и токена доступа. Эти токены могут иметь любое строковое значение, но они должны однозначно представлять пользователя и клиент, для которого предназначен токен, и их нельзя угадать. Для токенов доступа также укажите время истечения срока действия токена, которое обычно составляет час после его выдачи. Токены обновления не имеют срока действия.
6. В теле HTTPS-ответа возвращается следующий JSON-объект:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

Обменяйте токены обновления на токены доступа.

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

Для таких запросов значение параметра grant_type равно refresh_token , а значение refresh_token — это значение токена обновления, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен токена обновления на токен доступа:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

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

1. Убедитесь, что client_id идентифицирует источник запроса как Google, и что client_secret соответствует ожидаемому значению.
2. Убедитесь, что токен обновления действителен и что идентификатор клиента, указанный в запросе, совпадает с идентификатором клиента, связанным с токеном обновления.
3. Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с телом запроса {"error": "invalid_grant"} .
4. В противном случае используйте идентификатор пользователя из токена обновления для генерации токена доступа. Эти токены могут иметь любое строковое значение, но они должны однозначно представлять пользователя и клиент, для которого предназначен токен, и их нельзя угадать. Для токенов доступа также следует указать время истечения срока действия токена, обычно это час после его выдачи.
5. В теле HTTPS-ответа возвращается следующий JSON-объект:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

Обработка запросов информации о пользователях

Конечная точка userinfo — это ресурс, защищенный OAuth 2.0, который возвращает утверждения о связанном пользователе. Реализация и размещение конечной точки userinfo не является обязательной, за исключением следующих случаев использования:

• Вход в связанную учетную запись с помощью Google One Tap.
• Простая подписка на AndroidTV.

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

Например, если ваша конечная точка userinfo доступна по адресу https://myservice.example.com/userinfo , запрос может выглядеть следующим образом:

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

Чтобы ваша конечная точка userinfo могла обрабатывать запросы, выполните следующие действия:

1. Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
2. Если токен доступа недействителен, верните ошибку HTTP 401 Unauthorized с использованием заголовка ответа WWW-Authenticate . Ниже приведен пример ответа об ошибке с информацией о пользователе:

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

   Если в процессе связывания возвращается ошибка 401 Unauthorized или любой другой неудачный ответ об ошибке, ошибка будет невосстановимой, полученный токен будет отброшен, и пользователю придется снова инициировать процесс связывания.

3. Если токен доступа действителен, верните ответ HTTP 200 со следующим объектом JSON в теле ответа HTTPS:

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

   Если ваша конечная точка userinfo возвращает успешный ответ HTTP 200, полученный токен и утверждения регистрируются в учетной записи Google пользователя.

   ответ конечной точки с информацией о пользователе
   sub	Уникальный идентификатор, идентифицирующий пользователя в вашей системе.
   email	Адрес электронной почты пользователя.
   given_name	Необязательно: Имя пользователя.
   family_name	Необязательно: фамилия пользователя.
   name	Необязательно: Полное имя пользователя.
   picture	Необязательно: изображение профиля пользователя.

Проверка вашей реализации

Вы можете проверить свою реализацию, используя инструмент OAuth 2.0 Playground .

В инструменте выполните следующие действия:

1. Нажмите settings конфигурации », чтобы открыть окно «Конфигурация OAuth 2.0».
2. В поле «Процесс аутентификации OAuth» выберите «На стороне клиента» .
3. В поле «Конечные точки OAuth» выберите «Пользовательские» .
4. Укажите в соответствующих полях вашу конечную точку OAuth 2.0 и идентификатор клиента, который вы присвоили Google.
5. В разделе «Шаг 1» не выбирайте никаких областей действия Google. Вместо этого оставьте это поле пустым или введите область действия, действительную для вашего сервера (или произвольную строку, если вы не используете области действия OAuth). После завершения нажмите «Авторизовать API» .
6. В разделах «Шаг 2» и «Шаг 3» пройдите весь процесс аутентификации OAuth 2.0 и убедитесь, что каждый шаг работает должным образом.

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

В инструменте выполните следующие действия:

1. Нажмите кнопку « Войти через Google» .
2. Выберите учетную запись, которую хотите связать.
3. Введите идентификатор службы.
4. При желании укажите одну или несколько областей доступа, к которым вы запрашиваете доступ.
5. Нажмите «Начать демонстрацию» .
6. При появлении запроса подтвердите свое согласие и отклоните запрос на привязку.
7. Убедитесь, что вас перенаправили на вашу платформу.