Сценарий: управляющая программа, которая вызывает веб-API

  • Статья

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

Обзор

Приложение может получить маркер для вызова веб-интерфейса API от собственного имени (а не от имени пользователя). Этот сценарий используется для управляющих приложений. В нем используется стандартное предоставление учетных данных клиента OAuth 2.0.

Daemon apps

Ниже приведены некоторые примеры вариантов использования для приложений управляющей программы;

  • Веб-приложения, используемые для подготовки или администрирования пользователей или для выполнения пакетных процессов в каталоге
  • Классические приложения (например, службы Windows или управляющие программы на платформе Linux), которые выполняют пакетные задания или службу операционной системы, работающую в фоновом режиме
  • Веб-API, которые должны управлять каталогами, а не отдельными пользователями

Существует еще один распространенный случай, когда приложения, отличные от управляющей программы, используют учетные данные клиента, даже если они действуют от имени пользователей. Это происходит, когда им нужно получить доступ к веб-API или ресурсу в соответствии с техническими причинами. Примером является доступ к секретам в Azure Key Vault или базе данных SQL Azure для кэша.

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

Примеры приложений без управляющей программы:

  • мобильное приложение, которое обращается к веб-службе от имени приложения, но не от имени пользователя;
  • устройство Интернета вещей, которое обращается к веб-службе от имени устройства, но не от имени пользователя.

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

  • Конфиденциальные клиентские приложения, учитывая, что они получают доступ к ресурсам независимо от пользователей, должны подтвердить свою личность. Администраторы клиента Microsoft Entra должны предоставить разрешение этим довольно конфиденциальным приложениям.
  • Зарегистрировали секрет (пароль приложения или сертификат) с идентификатором Microsoft Entra. Этот секрет передается во время вызова идентификатора Microsoft Entra для получения маркера.

Особенности

Пользователи не могут взаимодействовать с приложением управляющей программы, так как для него требуется собственное удостоверение. Этот тип приложения запрашивает маркер доступа с помощью удостоверения приложения и представления идентификатора приложения, учетных данных (пароля или сертификата) и URI идентификатора приложения в идентификатор Microsoft Entra ID. После успешной проверки подлинности управляющая программа получает маркер доступа (и маркер обновления) от платформы удостоверений Майкрософт, который затем используется для вызова (и при необходимости — для обновления) веб-интерфейса API.

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

Для разработчиков работа в рамках такого сценария имеет описанные ниже особенности.

  • Приложения управляющей программы могут работать только в клиентах Microsoft Entra. Создавать управляющее приложение, которое пытается выполнять какие-либо операции с личными учетными записями Майкрософт, не имеет смысла. Если вы разрабатываете бизнес-приложения, вы создаете управляющие приложения в своем арендаторе. Если вы являетесь независимым поставщиком программного обеспечения, вам может потребоваться мультитенантная управляющая программа (для нескольких арендаторов). Каждому администратору клиента необходимо предоставить согласие.
  • Во время регистрации приложения URI ответа не требуется. Предоставление общего доступа к секретам или сертификатам или подписанным утверждениям с помощью идентификатора Microsoft Entra. Кроме того, потребуется запросить разрешения приложения и предоставить согласие администратора на их использование.
  • Конфигурация приложения должна предоставить учетные данные клиента в качестве общего доступа к идентификатору Microsoft Entra во время регистрации приложения.
  • Область, используемая для получения маркера с помощью потока учетных данных клиента, должна быть статической.

Если вы незнакомы с системой управления идентификацией и доступом (IAM) с помощью OAuth 2.0 и OpenID Connect или просто только начинаете работу с IAM на платформе удостоверений Майкрософт, вам обязательно следует прочитать следующие статьи.

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

Проверка подлинности и авторизация

Платформа удостоверений Майкрософт

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

Перейдите к следующей статье в этом сценарии, Регистрация приложения.