Соблюдайте правила OAuth 2.0

�� ��том руководстве рассказывается, как устранить самые распространенные проблемы, с которыми сталкиваются разработчики при подготовке приложения к публикации.

Обзор

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

Используйте разные проекты для тестирования и рабочей версии

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

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

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

Клиенты Google OAuth, используемые в рабочей среде, не должны содержать тестовые среды, URI перенаправления или источники JavaScript, доступные только вам или вашей команде разработчиков. Вот несколько примеров:

  • Тестовые серверы отдельных разработчиков.
  • Тестовые или предварительные версии приложения.

Вести список контактов, связанных с проектом.

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

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

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

Достоверность информации о себе

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

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

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

Запрашивайте только необходимые области действия

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

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

Дополнительную информацию об этом требовании можно найти в разделе Запрашивайте только необходимые области действия правил OAuth 2.0 и в разделе Запрашивайте только необходимые разрешения правил в отношении пользовательских данных при использовании API Google.

Отправьте на проверку рабочие приложения, которые используют общедоступные области действия или области действия, не относящиеся к конфиденциальным данным

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

Мы настоятельно рекомендуем размещать кнопку входа в соответствии с официальными правилами фирменного оформления.

Используйте только принадлежащие вам домены

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

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

Разместить главную страницу для рабочих версий приложений.

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

На главной странице приложения должно быть описание его функций, а также ссылки на политику конфиденциальности и условия использования (н��обязательно). Главная страница должна находиться в подтвержденном домене, который принадлежит вам.

Используйте безопасные URI перенаправления и источники JavaScript

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

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

Дальнейшие действия

Убедившись, что ваше приложение соответствует правилам OAuth 2.0, приведенным на этой странице, ознакомьтесь с информацией о том, как отправить приложение на проверку бренда.