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

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

Обзор

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

Daemon apps

Вот несколько примеров использования этого приема для управляющих приложений:

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

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

Примечание

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

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

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

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

  • Они являются конфиденциальными клиентскими приложениями. Поскольку они обращаются к ресурсам независимо от пользователей, эти приложения должны подтверждать свое удостоверение. Они также работают с довольно конфиденциальными данными. Эти приложения подлежат утверждению администраторами клиента Azure Active Directory (Azure AD).
  • Они зарегистрировали секрет (пароль приложения или сертификат) в Azure AD. Этот секрет передается в Azure AD во время вызова для получения маркера.

Особенности

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

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

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

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

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

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

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

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