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

Настройка токенов

Как разработчик, основное взаимодействие с Microsoft Entra ID заключается в запросе токена для идентификации пользователя. Вы также запрашиваете токен, чтобы получить доступ для вызова веб-API. Маркер веб-API определяет, что этот API может делать при выполнении определенного запроса. В этой статье вы узнаете о сведениях, которые можно получить в токенах и как можно их настроить. Эти рекомендации разработчика zero Trust повышают гибкость и контроль при повышении безопасности приложений с минимальными привилегиями.

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

API Microsoft Graph предоставляет надежный набор сведений о каталоге и данных в Microsoft 365. Вы можете разработать многофункциональную систему авторизации, опираясь на данные в Microsoft Graph. Например, вы можете получить доступ к данным из членства в группе пользователя, подробных данных профиля, SharePoint и Outlook для использования в решениях по авторизации. Вы можете включить данные авторизации в токен из Microsoft Entra ID.

Авторизация на уровне приложения

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

ИТ-специалисты могут предотвратить выдачу токенов любому приложению в рамках клиента с флагом, требующим назначения пользователя. Этот подход гарантирует, что только набор пользователей может войти в приложение. Без этого флага все пользователи в клиенте могут получить доступ к приложению. С помощью этого флага только назначенные пользователи и группы могут получить доступ к приложению. Когда назначенный пользователь обращается к приложению, приложение получает маркер. Если у пользователя нет назначения, приложение не получает маркер. Помните, что всегда следует аккуратно управлять запросами токенов, которые не получают ответов.

Методы настройки токена

Существует два способа кастомизации токенов: дополнительные утверждения и сопоставление утверждений.

Необязательные претензии

Необязательные утверждения определяют, какие утверждения вы хотите, чтобы идентификатор Microsoft Entra отправлял в виде токенов в ваше приложение. Необязательные утверждения можно использовать, чтобы:

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

Необязательные требования привязаны к объекту регистрации приложения с определенной схемой. Они применяются к приложению независимо от того, где оно выполняется. При написании мультиарендного приложения опциональные утверждения работают хорошо, поскольку они согласованы для всех арендаторов в идентификационной системе Microsoft Entra. Например, IP-адрес не зависит от клиента, а приложение имеет IP-адрес.

По умолчанию гостевые пользователи в арендаторе также могут войти в ваше приложение. Если вы хотите заблокировать гостевых пользователей, включите опциональное требование (acct). Если это 1, то у пользователя гостевая классификация. Если вы хотите заблокировать гостей, тогда заблокируйте токены с acct==1.

Политики сопоставления утверждений

В идентификаторе Microsoft Entra объекты политики представляют наборы правил для отдельных приложений или всех приложений в организации. Политика сопоставления утверждений изменяет утверждения, которые идентификатор Microsoft Entra ID выдает в токенах для определенных приложений.

Сопоставление утверждений используется для сведений, относящихся к арендатору, которые не имеют схемы (например, EmployeeID, DivisionName). Сопоставление утверждений применяется на уровне учетной записи службы, которая контролируется администратором арендатора. Сопоставление утверждений соответствует корпоративному приложению или основному компоненту службы, связанному с этим приложением. Каждый клиент может иметь собственное сопоставление утверждений.

При разработке отраслевого бизнес-приложения обратите особое внимание на то, что делает ваш арендатор (какие параметры у вашего арендатора доступны, которые можно использовать в вашем токене). Например, если у организации есть свойство название отдела пользователя (не является стандартным полем в Microsoft Entra ID) в локальном Active Directory, используйте Microsoft Entra Connect для синхронизации этого свойства с Microsoft Entra ID.

Чтобы содержать эти сведения, используйте один из стандартных атрибутов расширения. Определите токен с утверждением имени подразделения, которое можно создать из соответствующего расширения (даже если это не применяется для каждого арендатора). Например, организация помещает имя подразделения в атрибут расширения 13.

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

Настройка маркера плана

Какой маркер вы настраиваете, зависит от типа приложения: клиентского приложения или API. Нет разницы в том, что можно сделать для настройки токена. То, что можно поместить в токен, одинаково для каждого из них. Какой маркер вы выбираете для настройки, зависит от того, какой маркер использует приложение.

Кастомизация токенов идентификатора

Если вы разрабатываете клиентское приложение, настройте маркер идентификатора , так как это маркер, который вы запрашиваете для идентификации пользователя. Токен принадлежит вашему приложению, когда утверждение аудитории (aud) в токене совпадает с идентификатором приложения клиента. Для клиентского приложения, которое вызывает API, но не реализует их, убедитесь, что вы настраиваете только маркер идентификатора приложения.

Портал Azure и API Microsoft Graph позволяют настраивать маркер доступа для приложения, но эти настройки не влияют. Невозможно настроить маркер доступа для API, которым вы не управляете. Помните, что приложение не должно пытаться декодировать или проверять маркер доступа, который ваше клиентское приложение получает в качестве авторизации для вызова API.

Настройка токенов доступа

При разработке API вы настраиваете маркер доступа , так как API получает маркеры доступа в рамках вызова клиента к API.

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

Группы и роли приложения

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

Дальнейшие действия

  • Last updated on