Соблюдайте политики 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 Services.

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

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

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

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