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

,

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

,

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

,

Когда вы будете готовы развернуть внедренное решение за пределами среды разработки для пользователей вашего приложения, вам может потребоваться предпринять дополнительные шаги для обеспечения соответствия политикам 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. Например, пример Scope может запросить чтение, запись и удаление разрешений, в то время как ваше приложение требует только разрешения для чтения. Запросите соответствующие разрешения , которые ограничены критической информацией, необходимой для реализации вашей заявки.

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

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

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

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

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

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

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

Установить домашнюю страницу для производственных приложений

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

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

Используйте Secure Redirect Uris и JavaScript Origins

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

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

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

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