Управление маркерами для нулевого доверия

  • Статья

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

Убедитесь, что приложение соответствует принципу "Нулевое доверие" наименьших привилегий и предотвращает использование способами, которые скомпрометирует ваше намерение. Ограничьте доступ пользователей с помощью технологий JIT/JEA, а также адаптивных политик на основе рисков и средств защиты данных. Разделите конфиденциальные и мощные разделы приложения, предоставляя доступ только авторизованным пользователям к этим областям. Ограничить пользователей, которые могут использовать свое приложение и возможности, которые они имеют в приложении.

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

Упростить управление авторизацией в приложении клиентами. Уменьшите затраты на подготовку пользователей и потребность в ручных процессах. Автоматическая подготовка пользователей позволяет ИТ-администраторам автоматизировать создание, обслуживание и удаление пользовательских удостоверений в целевых хранилищах удостоверений. Клиенты могут использовать автоматизацию изменений для пользователей и групп с помощью подготовки приложений или подготовки на основе кадров в идентификаторе Microsoft Entra.

Использование утверждений маркера в приложениях

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

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

  • Утверждение аудитории (aud) — это идентификатор клиента вашего приложения. Примите только маркеры для идентификатора клиента API.
  • Утверждение tid — это идентификатор клиента, выдавшего маркер. Утверждение oid является неизменяемым значением, которое однозначно идентифицирует пользователя. Используйте уникальное сочетание утверждений tid и oid утверждений в качестве ключа, если необходимо связать данные с пользователем. Эти значения утверждений можно использовать для подключения данных к идентификатору пользователя в идентификаторе Microsoft Entra ID.
  • Утверждение sub является неизменяемым значением, уникальным образом удостоверяющим пользователя. Утверждение субъекта также уникально для приложения. Если вы используете sub утверждение для связывания данных с пользователем, невозможно перейти из данных и подключить его к пользователю в идентификаторе Microsoft Entra.

Приложения могут использовать openid область для запроса маркера идентификатора из платформа удостоверений Майкрософт. Стандарт OIDC управляет openid область вместе с форматом и содержимым маркера идентификатора. OIDC указывает следующие область:

  • openid Используйте область для входа пользователя и добавления sub утверждения в маркер идентификатора. Эти область предоставляют идентификатор пользователя, уникальный для приложения и пользователя, и вызывает конечную точку UserInfo.
  • Область email добавляет email утверждение, содержащее адрес электронной почты пользователя к маркеру идентификатора.
  • Область profile добавляет утверждения с основными атрибутами профиля пользователя (имени, имени пользователя) в маркер идентификатора.
  • Область offline_access позволяет приложению получать доступ к данным пользователей, даже если пользователь не присутствует.

Библиотека проверки подлинности Майкрософт (MSAL) всегда добавляет открытый идентификатор, электронную почту и profile область в каждый запрос маркера. В результате MSAL всегда возвращает маркер идентификатора и маркер доступа при каждом вызове AcquireTokenSilent или AcquireTokenInteractive. MSAL всегда запрашивает offline_access область. Платформа удостоверений Майкрософт всегда возвращает offline_access область даже если запрашивающее приложение не указывает offline_access область.

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

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

После авторизации платформа удостоверений Майкрософт возвращает маркер доступа приложению. При вызове ресурса приложение предоставляет этот маркер в качестве части заголовка авторизации HTTP-запроса к API.

Управление временем существования маркера

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

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

Как правило, маркеры должны быть допустимыми и неиспользоваными. Утверждение аудитории (aud) должно соответствовать идентификатору клиента. Убедитесь, что маркер поступает от доверенного издателя. Если у вас есть мультитенантный API, можно отфильтровать, чтобы только определенные клиенты могли вызывать API. Убедитесь, что вы применяете время существования маркера. nbf Проверьте утверждения (не раньше) и exp (срок действия), чтобы убедиться, что текущее время находится в значениях этих двух утверждений.

Не стремитесь к исключительно длинным или коротким срокам существования сеанса. Разрешите этому решению предоставленный маркер идентификатора время существования . Сохранение активности сеансов приложения за пределами допустимости маркеров нарушает правила, политики и проблемы, которые привели ИТ-администратора установить срок действия маркера, чтобы предотвратить несанкционированный доступ. Короткие сеансы ухудшают взаимодействие с пользователем и не обязательно повышают уровень безопасности. Популярные платформы, такие как ASP.NET позволяют задавать время ожидания сеанса и файлов cookie из времени истечения срока действия маркера идентификатора Идентификатора Microsoft Entra ID. После истечения срока действия маркера поставщика удостоверений гарантирует, что сеансы пользователя никогда не длиннее политик, которые диктует поставщик удостоверений.

Кэширование и обновление маркеров

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

Библиотеки MSAL управляют сведениями протокола OAuth2, включая механику обновления маркеров. Если вы не используете MSAL, убедитесь, что ваша библиотека будет эффективно использовать маркеры обновления.

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

Управление ошибками маркеров и ошибками

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

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

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

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

В коде проверка для классов ошибок, а не отдельных случаев ошибок. Например, обработайте взаимодействие с пользователем, а не отдельные ошибки, в которых система не предоставила разрешения. Так как вы можете пропустить эти отдельные случаи, лучше проверка для классификатора, например взаимодействия с пользователем, а не копаться в отдельных кодах ошибок.

Возможно, вам потребуется вернуться к AcquireTokenInteractive запросу и предоставить запросы на утверждения, необходимые AcquireTokenSilent для вызова. Это обеспечивает эффективное управление интерактивным запросом.

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