Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Узнайте, как создать устойчивость в клиентских приложениях, использующих платформу удостоверений Майкрософт и идентификатор Microsoft Entra для входа пользователей, а также выполнять действия от имени этих пользователей.
Использование библиотеки проверки подлинности Майкрософт (MSAL)
Библиотека проверки подлинности Майкрософт (MSAL) является частью платформы удостоверений Майкрософт. MSAL получает, управляет, кэширует и обновляет токены; в нем используются лучшие практики для обеспечения устойчивости. MSAL помогает разработчикам создавать безопасные решения.
Подробнее:
- Обзор библиотеки проверки подлинности Майкрософт
- Что такое платформа удостоверений Майкрософт?
- Документация по платформе идентификаций Майкрософт
MSAL кэширует токены и использует шаблон тихого получения токенов. MSAL сериализует кэш токенов в операционных системах, которые обладают встроенной возможностью безопасного хранения, таких как Универсальная Платформа Windows (UWP), iOS и Android. Настройте поведение сериализации при использовании:
- Microsoft.Identity.Web
- MSAL.NET
- MSAL для Java
- MSAL для Python
Подробнее:
При использовании MSAL поддерживается кэширование токенов, их обновление и тихое получение. Используйте простые шаблоны для получения токенов для аутентификации. Существует поддержка многих языков. Найдите пример кода в примерах кода платформы удостоверений Майкрософт.
try
{
result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}
MSAL может обновлять токены. Когда платформа идентификации Microsoft выдает долгоживущие токены, она может отправлять клиенту сведения для их обновления (refresh_in). Приложение запускается, пока старый маркер действителен, но требуется больше времени для получения другого маркера.
Выпуски MSAL
Мы рекомендуем разработчикам создавать процесс для использования последнего выпуска MSAL, так как проверка подлинности является частью безопасности приложений. Используйте эту практику для библиотек в процессе разработки и повышения устойчивости приложений.
Найдите последнюю версию и заметки о выпуске:
microsoft-authentication-library-for-js
microsoft-authentication-library-for-dotnet
microsoft-authentication-library-for-python
microsoft-authentication-library-for-java
microsoft-authentication-library-for-objc
microsoft-authentication-library-for-android
microsoft-identity-web
Надёжные шаблоны для обработки токенов
Если вы не используете MSAL, используйте устойчивые шаблоны для обработки токенов. Библиотека MSAL реализует рекомендации.
Как правило, приложения, использующие современную проверку подлинности, вызывают конечную точку, чтобы получить маркеры для проверки подлинности пользователя или авторизовать приложение для вызова защищённых API. MSAL обрабатывает проверку подлинности и реализует шаблоны для повышения устойчивости. Если вы не используете MSAL, воспользуйтесь рекомендациями в этом разделе. В противном случае MSAL реализует рекомендации автоматически.
Система проверки подлинности резервного копирования идентификатора Microsoft Entra обеспечивает устойчивость приложений, использующих поддерживаемые протоколы и потоки. Дополнительные сведения о требованиях к приложению для получения преимуществ от проверки подлинности резервного копирования см. в требованиях к приложению для системы проверки подлинности резервного копирования.
Кэширование маркеров
Убедитесь, что приложения точно кэшируют токены с платформы идентификации Microsoft. После получения токенов HTTP-ответ с токенами имеет свойство expires_in
, указывающее время для кэширования и повторного использования. Убедитесь, что приложение не пытается декодировать маркер доступа API.
Кэшированные маркеры предотвращают ненужный трафик между приложением и платформой удостоверений Майкрософт. Этот сценарий делает приложение менее уязвимым к сбоям получения токенов, уменьшая количество вызовов для их получения. Кэшированные токены повышают производительность приложения, так как приложение реже блокируется при получении токенов. Пользователи остаются вошедшими в приложение в течение времени жизни токена.
Сериализуйте и сохраните токены
Убедитесь, что приложения безопасно сериализуют кэш маркеров, чтобы сохранить маркеры между экземплярами приложений. Повторное использование маркеров на протяжении их срока службы. Токены обновления и токены доступа выдаются на многие часы. В это время пользователи могут запускать приложение несколько раз. При запуске приложения убедитесь, что он ищет допустимый доступ или маркер обновления. Это повышает устойчивость и производительность приложения.
Подробнее:
Убедитесь, что постоянное хранилище маркеров имеет управление доступом и шифрование в отношении владельца пользователя или идентификатора процесса. В различных операционных системах существуют функции хранения учетных данных.
Получение токенов в фоновом режиме
Проверка подлинности пользователя или получение авторизации для вызова API подразумевает несколько шагов на платформе удостоверений Майкрософт. Например, пользователи впервые вводят учетные данные и проходят многофакторную проверку подлинности. Каждый шаг влияет на ресурс, предоставляющий службу. Оптимальный пользовательский опыт с наименьшими зависимостями — это тихое получение токена.
Тихое получение маркера начинается с действительного маркера из кэша маркеров приложения. Если нет действительного токена, приложение пытается получить токен с помощью доступного токена обновления и конечной точки токена. Если этот параметр недоступен, приложение получает маркер с помощью prompt=none
параметра. Это действие использует конечную точку авторизации, но для пользователя не отображается пользовательский интерфейс. Если возможно, платформа удостоверений Microsoft предоставляет токен приложению без взаимодействия с пользователем. Если ни один метод не приводит к токену, пользователь вручную повторно проходит аутентификацию.
Замечание
Как правило, убедитесь, что приложения не используют такие запросы, как "login" и "consent". Эти запросы заставляют пользователя взаимодействовать, когда взаимодействие не требуется.
Обработка кода ответа
Используйте следующие разделы, чтобы узнать о кодах ответов.
Код ответа HTTP 429
Существуют ответы на ошибки, влияющие на устойчивость. Если ваше приложение получает код ответа HTTP 429 (слишком много запросов), платформа удостоверений Microsoft ограничивает ваши запросы. Если приложение выполняет слишком много запросов, его работа попадает под ограничение скорости, чтобы предотвратить получение токенов. Не позволяйте приложению пытаться получить токен до тех пор, пока не истечет время из поля ответа Retry-After. Часто ответ 429 указывает на то, что приложение неправильно кэширует и повторно использует токены. Подтвердите, как кэшируются и повторно используются токены в приложении.
Код ответа HTTP 5x
Если приложение получает код ответа HTTP 5x, приложение не должно вводить быстрый цикл повторных попыток. Используйте ту же обработку для ответа 429. Если нет заголовка Retry-After, реализуйте экспоненциальную повторную попытку при первой попытке, по крайней мере через 5 секунд после ответа.
При истечении времени ожидания запроса не рекомендуется немедленно повторять его. Реализуйте экспоненциальную повторную попытку с первым повторным повтором, по крайней мере через 5 секунд после ответа.
Получение сведений, связанных с авторизацией
Для авторизации многих приложений и API требуется информация о пользователях. Доступные методы имеют преимущества и недостатки.
Токены
Токены удостоверений (ID) и токены доступа содержат стандартные утверждения, предоставляющие информацию. Если необходимая информация содержится в токене, наиболее эффективным методом является использование утверждений в токене, поскольку это предотвращает совершение дополнительного сетевого вызова. Меньше сетевых вызовов приравнивают к лучшей устойчивости.
Подробнее:
- Токены идентификации платформы Microsoft
- токены доступа платформы управления идентификацией Microsoft
Замечание
Некоторые приложения обращаются к конечной точке UserInfo, чтобы получить информацию о пользователе, прошедшем проверку подлинности. Сведения в токене идентификатора — это супермножество сведений из конечной точки userinfo. Разрешить приложениям использовать токен идентификатора вместо обращения к конечной точке UserInfo.
Дополнение стандартных утверждений маркера необязательными утверждениями, такими как группы. Параметр "Группа приложений" включает группы, назначенные приложению. Параметры "Все" или "Группы безопасности" включают группы из приложений в одном тенанте, которые могут добавлять группы в токен. Оцените эффект, так как он может свести на нет эффективность запросов данных о группах в токене, вызвав утяжеление токена и приведя к необходимости дополнительных вызовов для получения групп.
Подробнее:
Мы рекомендуем использовать и включать роли приложений, которыми клиенты управляют с помощью портала или API. Назначение ролей пользователям и группам для управления доступом. Когда токен выпускается, назначенные роли находятся в утверждении токена. Сведения, производные от токена, ограничивают количество запросов к API.
Добавьте роли приложений в свое приложение и получите их в токене
Добавьте утверждения на основе сведений об арендаторе. Например, расширение имеет идентификатор пользователя для конкретного предприятия.
Добавление сведений из каталога в токен является эффективным и повышает устойчивость путем уменьшения зависимостей. Это не решает проблемы устойчивости из-за невозможности получения токена. Добавьте необязательные утверждения для основных сценариев приложения. Если приложению требуются сведения для административных функций, приложение может получить эти сведения по мере необходимости.
Microsoft Graph
Microsoft Graph имеет единую конечную точку API для доступа к данным Microsoft 365 о показателях производительности, идентификации и безопасности. Приложения с помощью Microsoft Graph могут использовать сведения Microsoft 365 для авторизации.
Для приложений требуется один маркер для доступа к Microsoft 365, который является более устойчивым, чем предыдущие API для компонентов Microsoft 365, таких как Microsoft Exchange или Microsoft SharePoint, которые требовали несколько маркеров.
При использовании API Microsoft Graph используйте пакет SDK Microsoft Graph, упрощающий создание устойчивых приложений, обращаюющихся к Microsoft Graph.
Общие сведения о пакете SDK Для Microsoft Graph
Для авторизации рекомендуется использовать утверждения токенов вместо некоторых вызовов Microsoft Graph. Группы запросов, роли приложения и необязательные утверждения в токенах. Для авторизации Microsoft Graph требуется больше сетевых вызовов, использующих платформу удостоверений Майкрософт и Microsoft Graph. Однако если ваше приложение использует Microsoft Graph в качестве уровня данных, использование Microsoft Graph для авторизации не представляет большего риска.
Использование проверки подлинности брокера на мобильных устройствах
На мобильных устройствах брокер проверки подлинности, такой как Microsoft Authenticator, повышает устойчивость. Брокер проверки подлинности использует первичный маркер обновления (PRT) с утверждениями о пользователе и устройстве. Используйте PRT для токенов аутентификации, чтобы получить доступ к другим приложениям с устройства. Когда PRT запрашивает доступ к приложению, Microsoft Entra ID доверяет устройству, связанному с PRT, и утверждениям MFA. Это повышает устойчивость, уменьшая действия по проверке подлинности устройства. Пользователи не сталкиваются с несколькими запросами MFA на одном устройстве.
См. раздел " Что такое основной маркер обновления"?
MSAL поддерживает проверку подлинности брокера. Подробнее:
- Единый вход через брокер аутентификации на iOS
- Включение единого входа между приложениями в Android с помощью MSAL
Непрерывная оценка доступа
Непрерывная оценка доступа (CAE) повышает безопасность приложений и устойчивость с помощью долгосрочных маркеров. При использовании CAE маркер доступа отменяется на основе критических событий и оценки политики, а не краткого времени существования маркеров. Для некоторых ресурсов API, поскольку риск и политика оцениваются в режиме реального времени, CAE увеличивает время существования токена до 28 часов. MSAL обновляет долгосрочные токены.
Подробнее:
- Непрерывная оценка доступа
- Защита приложений с помощью непрерывной оценки доступа
- Оценка критических событий
- Оценка политики условного доступа
- Как использовать API с поддержкой CAE в ваших приложениях
Если вы разрабатываете API-интерфейсы ресурсов, перейдите в openid.net
раздел "Общие сигналы" — безопасная платформа веб-перехватчиков.
Дальнейшие шаги
- Как использовать API с поддержкой CAE в ваших приложениях
- Повышение устойчивости проверки подлинности и авторизации в разрабатываемых вами фоновых приложениях
- Создание устойчивости в инфраструктуре управления удостоверениями и доступом
- Создание устойчивости в управлении удостоверениями клиентов и доступом с помощью Azure AD B2C