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

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

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

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

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

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. Просмотрите клиенты OAuth в этом проекте, которые могут быть связаны с вашим уровнем тестирования. Если применимо, создайте аналогичные клиенты OAuth для рабочих клиентов внутри вашего производственного проекта.
  3. Включите все API, используемые вашими клиентами.
  4. Проверьте конфигурацию экрана согласия OAuth в новом проекте.

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

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

Ведение списка актуальных контактов для проекта

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

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

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

Точно представлять свою личность

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

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

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

Запрашивайте только те области, которые вам нужны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги

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