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

Защита приложений и API путем проверки утверждений

  • Статья

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

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

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

  • Для маркера указана соответствующая аудитория.
  • Идентификатор клиента маркера соответствует идентификатору клиента, в котором хранятся данные.
  • Тема маркера подходит.
  • Субъект (клиентское приложение) авторизован.

Примечание.

Маркеры доступа проверяются только в веб-API, для которых они были приобретены клиентом. Клиент не должен проверять маркеры доступа.

Дополнительные сведения о утверждениях, упомянутых в этой статье, см. в платформа удостоверений Майкрософт маркерах доступа.

Проверка аудитории

Утверждение aud определяет целевую аудиторию маркера. Перед проверкой утверждений необходимо всегда убедиться, что значение aud утверждения, содержащегося в маркере доступа, соответствует веб-API. Значение может зависеть от того, как клиент запросил маркер. Аудитория в маркере доступа зависит от конечной точки:

  • Для токенов версии 2.0 аудитория — это идентификатор клиента веб-API. Это GUID.
  • Для токенов версии 1.0 аудитория является одним из URI appID, объявленных в веб-API, который проверяет маркер. Например, или уникальное имя, api://{ApplicationID}начинающееся с доменного имени (если доменное имя связано с клиентом).

Дополнительные сведения о URI appID приложения см. в разделе URI идентификатора приложения.

Проверка клиента

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

Проверка клиента — это только первый шаг, и проверки темы и субъекта, описанные в этой статье, по-прежнему необходимы. Если вы намерены авторизовать всех пользователей в клиенте, настоятельно рекомендуется явно добавить этих пользователей в группу и авторизовать их на основе группы. Например, проверяя только идентификатор клиента и наличие oid утверждения, API может непреднамеренно авторизовать все субъекты-службы в этом клиенте в дополнение к пользователям.

Проверка темы

Определите, авторизован ли субъект маркера, например пользователь (или приложение для маркера только для приложения).

Можно проверить наличие конкретных sub или oid утверждений.

или

Вы можете проверить, принадлежит ли субъект соответствующей роли или группе с rolesпомощью , , scpgroupswids утверждений. Например, используйте неизменяемые значения tid утверждений и oid в качестве объединенного ключа для данных приложения и определите, должен ли пользователь предоставлять доступ.

groups Утверждения rolesили wids утверждения также можно использовать для определения того, имеет ли субъект авторизацию для выполнения операции, хотя они не являются исчерпывающим списком всех способов предоставления субъектом разрешений. Например, администратор может иметь разрешение на запись в API, но не обычный пользователь, или пользователь может находиться в группе, разрешенной для выполнения некоторых действий. Утверждение wid представляет роли на уровне клиента, назначенные пользователю из ролей, присутствующих в встроенных ролях Microsoft Entra. Дополнительные сведения см. в статье Встроенные роли Microsoft Entra.

Предупреждение

Никогда не используйте такие утверждения, как emailили preferred_username unique_name хранить или определять, должен ли пользователь в маркере доступа иметь доступ к данным. Эти утверждения не являются уникальными и могут управляться администраторами клиента или иногда пользователями, что делает их непригодными для принятия решений по авторизации. Они доступны только для использования в целях отображения. Кроме того, не используйте upn утверждение для авторизации. Хотя имя участника-пользователя уникально, он часто изменяется в течение всего времени существования участника-пользователя, что делает его ненадежным для авторизации.

Проверка субъекта

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

Однако существуют вхождения, в которых scp нет в маркере. Необходимо проверить отсутствие scp утверждения для следующих сценариев:

  • Приложения управляющей программы или разрешения только для приложений
  • Токен идентификатора

Дополнительные сведения о областях и разрешениях см. в разделе "Области и разрешения" в платформа удостоверений Майкрософт.

Примечание.

Приложение может обрабатывать маркеры только для приложений (запросы от приложений без пользователей, таких как приложения управляющей программы) и хотят авторизовать конкретное приложение в нескольких клиентах, а не отдельные идентификаторы субъектов-служб. В этом случае appid утверждение (для токенов версии 1.0) или azp утверждение (для токенов версии 2.0) можно использовать для авторизации субъекта. Однако при использовании этих утверждений приложение должно убедиться, что маркер был выдан непосредственно для приложения, проверяя необязательное idtyp утверждение. Таким образом можно авторизовать только маркеры типа app , так как делегированные маркеры пользователей могут быть потенциально получены сущностями, кроме приложения.

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