Соблюдайте политику OAuth 2.0.

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

Обзор

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

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

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

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

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

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

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

Вести список контактных лиц, имеющих отношение к проекту.

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

A role contains a set of permissions that lets you perform specific actions on project resources. Project editors have permissions for actions that modify state, such as the ability to make changes to your project's OAuth consent screen. Project owners who have all editor permissions can add or remove accounts associated with the project, or delete the project. Project owners can also provide context for why billing information might be set. Project owners can set up billing information for a project that uses paid APIs.

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

Точно отразите свою личность.

Укажите допустимое название приложения и, при желании, логотип для отображения пользователям. Эта информация о бренде должна точно отражать идентичность вашего приложения. Информация о брендинге приложения настраивается на странице «Брендинг OAuth».

For production apps, brand information defined in your OAuth consent screen must be verified before it displays to users. Users might be more likely to grant access to your app after it completes its brand verification. Basic application information, which includes the app's name, home page, terms of service, and privacy policy, are shown to users on the grant screen, when they review their existing grants, or to Google Workspace administrators that review app use by their organization.

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

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

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

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

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

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

При аутентификации пользователя функция «Вход через 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, описанным на этой странице, ознакомьтесь с разделом «Отправить на проверку бренда» для получения подробной информации о процессе проверки.