Google представила настройки управления доступом к приложениям, чтобы администраторам Google Workspace for Education было проще контролировать доступ сторонних приложений к данным Google их организаций при входе пользователей в систему с использованием учётных записей Google Workspace for Education. Хотя от разработчиков сторонних приложений никаких действий не требуется, ниже приведены некоторые рекомендации, которые другие разработчики сочли полезными.
Использовать инкрементный OAuth
Вы можете использовать поэтапную авторизацию , чтобы изначально запросить только те области, которые необходимы для запуска приложения, а затем запрашивать дополнительные области по мере необходимости. Контекст приложения затем определяет причину запроса для пользователя.
При входе в систему ваше приложение запрашивает базовые области действия, такие как профиль области действия входа и другие начальные области действия, необходимые приложению для работы. Позже, когда пользователь захочет выполнить действие, требующее дополнительных областей действия, ваше приложение запрашивает эти дополнительные области действия, и пользователь авторизует только новые области действия на экране согласия.
При создании надстройки для Google Класса необходимо следовать рекомендациям Google Workspace Marketplace и предоставить полный список областей действия OAuth, необходимых вашему приложению. Это необходимо для того, чтобы администратор понимал, на какие области действия у пользователя домена запрашивается согласие.
Убедитесь, что все приложения проверены OAuth
Все приложения, обращающиеся к API Google, должны подтвердить , что они точно отражают их идентификационные данные и намерения, как указано в Политике Google в отношении пользовательских данных API-сервисов. Если у вас несколько приложений, использующих API Google, убедитесь, что каждое из них прошло проверку. Администраторы могут видеть все идентификаторы клиентов OAuth, связанные с вашим проверенным брендом. Чтобы помочь администраторам избежать настройки неверных идентификаторов клиентов OAuth, используйте отдельные проекты Google Cloud для тестирования и производства и удалите все неиспользуемые идентификаторы клиентов OAuth.
Верификация OAuth API — это процесс, который Google Cloud Platform использует для обеспечения безопасности и соответствия приложений, запрашивающих конфиденциальные или ограниченные области действия, требованиям. Процесс верификации помогает защитить пользователей и данные Google Cloud от несанкционированного доступа.
Приложения, запрашивающие конфиденциальные или ограниченные области действия, должны соответствовать Политике в отношении пользовательских данных API сервисов Google. Эта политика требует от приложений защищать пользовательские данные и использовать их только в целях, разрешенных пользователем. Приложениям также может потребоваться пройти независимую оценку безопасности для подтверждения их соответствия требованиям безопасности Google Cloud.
Обратите внимание, что процесс проверки API OAuth может занять до нескольких недель. После завершения проверки вы сможете запросить необходимые вам конфиденциальные или ограниченные области действия.
Более подробную информацию см. в разделе часто задаваемых вопросов по проверке API OAuth .
Обработка нескольких идентификаторов клиентов OAuth
Проект Google Cloud может иметь несколько идентификаторов клиентов OAuth, что может потребовать от администратора домена многократной настройки вашего доступа.
Обеспечьте точность идентификаторов клиентов OAuth
Уточните у своей команды разработчиков, какие идентификаторы клиентов OAuth используются для интеграции с Google OAuth. Используйте два разных проекта Google Cloud для тестирования и рабочей среды , чтобы администраторам было проще понять, какие идентификаторы клиентов OAuth следует настраивать. Удалите все устаревшие или неактуальные идентификаторы клиентов из своих рабочих проектов.
загрузка CSV-файла
Если у вас несколько идентификаторов клиентов, мы рекомендуем использовать функцию массовой загрузки CSV-файлов , чтобы администраторы могли быстро настроить все ваши приложения.
Поля:
| Поле | Необходимый | Примечания |
|---|---|---|
| Название приложения | Нет | Введите название приложения. Изменения названия приложения в CSV-файле не отражаются в консоли администратора. |
| Тип | Да | Одно из веб-приложений , Android или iOS . |
| Идентификатор | Да | Для веб-приложений введите идентификатор клиента OAuth, выданный приложению. Для приложений Android и iOS введите идентификатор клиента OAuth или идентификатор пакета или комплекта, который приложение использует в Google Play или магазине приложений Apple. |
| Организационная единица | Да | Заполняется заказчиком. Введите косую черту ('/'), чтобы применить настройки доступа к приложению ко всему домену. Чтобы применить настройки доступа к определённым организационным подразделениям, добавьте в электронную таблицу строку для каждого подразделения, повторив имя приложения, его тип и идентификатор (например, '/org_unit_1/sub_unit_1'). |
| Доступ | Да | Один из вариантов: доверенный , заблокированный или ограниченный . |
Ошибки OAuth
В новых элементах управления администратора появились два сообщения об ошибках.
- Ошибка 400: access_not_configured — возникает, когда соединение OAuth отклонено, поскольку ваше приложение не настроено.
- Ошибка 400: admin_policy_enforced — возникает, когда соединение OAuth отклонено, поскольку администратор заблокировал ваше приложение.
Пользователи, которым меньше 18 лет
Администраторы могут управлять доступом к ненастроенным сторонним приложениям для пользователей младше 18 лет. Если пользователь сталкивается с ошибкой «Доступ заблокирован: администратору вашего учреждения необходимо проверить [название приложения]», он должен запросить доступ, используя сообщение об ошибке. Это позволит администратору проверить стороннее приложение. Администраторы могут разрешить или запретить использование сторонних приложений.