Поделиться через


Рекомендации и советы по платформе удостоверений Майкрософт

В этой статье описываются лучшие методики, рекомендации и общие сведения об интеграции с платформой удостоверений Майкрософт. Этот контрольный список поможет вам обеспечить высококачественную и безопасную интеграцию. Регулярно просматривайте этот список, чтобы обеспечить качество и безопасность интеграции приложения с платформой удостоверений. Контрольный список не предназначен для проверки всего вашего приложения. Содержимое контрольного списка может быть изменено по мере внесения улучшений в платформу.

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

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

Совет

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

Основные сведения

флажок Чтение и понимание политик платформы Майкрософт. Убедитесь, что ваше приложение соответствует описанным условиям, которые были разработаны для защиты пользователей и платформы.

Тип собственности

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

Фирменная символика

флажок Соблюдайте рекомендации по фирменной символии для приложений.

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

Конфиденциальность

флажок Укажите ссылки на условия обслуживания и заявление о конфиденциальности приложения.

Безопасность

флажок Управление URI перенаправления:

  • Поддерживайте владение всеми своими URI перенаправления и актуальность всех их записей DNS.
  • Не используйте подстановочные знаки (*) в универсальных кодах ресурса (URI).
  • Все URI перенаправления для веб-приложений должны быть защищены и зашифрованы (например, с помощью схем HTTPS).
  • Для общедоступных клиентов используйте URI перенаправления платформы, если это возможно (в основном это относится к iOS и Android). В противном случае используйте максимально случайные URI перенаправления, чтобы избежать конфликтов при обратном вызове приложения.
  • Если приложение используется изолированным веб-агентом, вы можете использовать https://login.microsoftonline.com/common/oauth2/nativeclient.
  • Регулярно просматривайте список URI перенаправления и удаляйте из него неиспользуемые или ненужные URI.

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

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

флажок Переход за рамки имени пользователя или пароля. Не используйте поток учетных данных владельца ресурса (ROPC), который напрямую обрабатывает пароли пользователей. Этот поток требует высокого уровня доверия и создает уязвимость для пользователей, поэтому его следует использовать только в том случае, когда использовать более безопасный поток невозможно. Этот поток по-прежнему необходим в некоторых сценариях (например, DevOps), но следует помнить, что его использование накладывает ограничения на приложение. Более современные подходы описаны в разделе Потоки проверки подлинности и сценарии приложений.

флажок Защита учетных данных конфиденциальных приложений и управление ими для веб-приложений, веб-API и управляющих приложений. Используйте учетные данные сертификата, а не учетные данные пароля (секреты клиента). Если необходимо использовать учетные данные пароля, не задавайте их вручную. Не храните учетные данные в коде или конфигурации и никогда не разрешайте пользователям обрабатывать их. По возможности используйте управляемые удостоверения для ресурсов Azure или Azure Key Vault для хранения и регулярной смены учетных данных.

флажок Убедитесь, что приложение запрашивает минимальные разрешения привилегий. Запрашивайте только разрешения, необходимые приложению, и только тогда, когда это необходимо. Изучите общие сведения о типах разрешений. При необходимости используйте только разрешения приложения. По возможности используйте делегированные разрешения. Полный список разрешений Microsoft Graph приведен в этом справочнике по разрешениям.

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

Внедрение

флажок Используйте современные решения проверки подлинности (OAuth 2.0, OpenID Connect) для безопасного входа пользователей.

флажок Не программируете напрямую протоколы, такие как OAuth 2.0 и Open ID. Вместо этого используйте библиотеку проверки подлинности Майкрософт (MSAL). Библиотеки MSAL безопасно переносят протоколы безопасности в удобную библиотеку, и вы получаете встроенную поддержку сценариев условного доступа, единый вход на уровне устройства и встроенную поддержку кэширования маркеров. Дополнительные сведения приведены в списке клиентских библиотек, поддерживаемых корпорацией Майкрософт. Если необходимо вручную запрограммировать протоколы проверки подлинности, следуйте рекомендациям Microsoft SDL или аналогичной методологии разработки. Обратите особое внимание на вопросы безопасности в спецификациях стандартов для каждого протокола.

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

флажокПеренос существующих приложений из библиотеки проверки подлинности Azure Active Directory (ADAL) в библиотеку проверки подлинности Майкрософт. MSAL — это последнее решение платформы удостоверений Майкрософт и доступно в .NET, JavaScript, Android, iOS, macOS, Python и Java. Узнайте больше о переносе приложений ADAL.NET и ADAL.js, а также приложений брокера ADAL.NET и iOS.

флажок Для мобильных приложений настройте каждую платформу с помощью интерфейса регистрации приложений. Чтобы приложение пользовалось преимуществами Microsoft Authenticator или Microsoft Корпоративный портал для единого входа, ваше приложение должно настроить URI перенаправления брокера. Это позволит корпорации Майкрософт возвращать управление приложению после завершения проверки подлинности. При настройке каждой платформы процедура регистрации приложения будет предоставлять необходимые инструкции. Скачайте рабочий пример с помощью краткого руководства. В iOS по возможности используйте брокеры и системное веб-представление.

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

флажок Если данные, необходимые приложению, доступны через Microsoft Graph, запросите разрешения для этих данных с помощью конечной точки Microsoft Graph, а не отдельного API.

Взаимодействие с конечным пользователем

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

флажок Свести к минимуму количество попыток ввода учетных данных для входа пользователя при использовании приложения путем попытки автоматической проверки подлинности (автоматическое получение маркера) перед интерактивными потоками.

флажок Не используйте "prompt=consent" для каждого входа. Используйте только запрос на согласие, если вы определили, что вам нужно запросить согласие на получение дополнительных разрешений (например, если вы изменили необходимые разрешения приложения).

флажок Если применимо, обогатите приложение данными пользователей. Это удобно делать с помощью API Microsoft Graph. Приступить к работе вам поможет инструмент Graph Explorer.

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

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

Тестирование

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

флажок Протестируйте приложение со всеми возможными учетными записями, которые вы планируете поддерживать (например, рабочие или учебные учетные записи, личные учетные записи Майкрософт, дочерние учетные записи и суверенные учетные записи).

Дополнительные ресурсы

Ниже приведены ресурсы с подробными сведениями о версии 2.0: