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

Приложения для взаимодействия между службами

  • Статья

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

В этом руководстве используется устаревшая конечная точка Azure Active Directory версии 1.0. Для новых проектов используйте платформу удостоверений Майкрософт.

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

  • Управляющая программа, которому нужно вызывать веб-API, на основе типа предоставления разрешений учетных данных клиента OAuth 2.0.

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

  • Серверное приложение (например, веб-API), которому нужно вызывать веб-API, на основе проекта спецификации On-Behalf-Of в OAuth 2.0.

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

Схема

Схема

Поток использования протокола

Удостоверение приложения с предоставлением учетных данных клиента OAuth 2.0

  1. Сначала серверное приложение должно пройти проверку подлинности в Azure AD от своего имени, без участия пользователя (то есть без интерактивного диалогового окна входа). Оно отправляет запрос к конечной точке маркера Azure AD, предоставляя учетные данные, идентификатор приложения и универсальный код ресурса (URI) идентификатора приложения.
  2. Azure AD проверяет подлинность приложения и возвращает маркер доступа JWT, который используется для вызова веб-интерфейса API.
  3. Веб-приложение использует возвращенный маркер доступа JWT, добавляя строку JWT с обозначением "Носитель" в заголовок авторизации запроса, отправляемого по протоколу HTTPS в веб-интерфейс API. Затем веб-интерфейс API проверяет этот маркер JWT, и, если проверка будет выполнена успешно, возвращает требуемый ресурс.

Делегированное удостоверение пользователя с проектом спецификации OAuth 2.0 On-Behalf-Of

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

  1. Нативное приложение отправляет маркер доступа в веб-интерфейс API первого уровня.
  2. Данный веб-API первого уровня отправляет запрос к конечной точке маркера Azure AD, предоставляя свои идентификатор приложения, учетные данные, а также маркер доступа пользователя. Кроме того, запрос отправляется с параметром on_behalf_of, указывающим, что веб-интерфейс API запрашивает новые маркеры для вызова нисходящего (подчиненного) веб-интерфейса API от имени исходного пользователя.
  3. Azure AD проверяет, что веб-интерфейс API первого уровня имеет разрешения на доступ к веб-интерфейсу API второго уровня, и проверяет запрос, возвращая маркер доступа JWT и маркер обновления JWT в веб-интерфейс API первого уровня.
  4. Затем по протоколу HTTPS веб-интерфейс API первого уровня вызывает веб-интерфейс API второго уровня, добавляя строку маркера в заголовок авторизации в запросе. Веб-интерфейс API первого уровня может продолжать вызывать веб-интерфейс API второго уровня до тех пор, пока маркеры доступа и обновления остаются действительными.

Примеры кода

См. примеры кода для управляющей программы или серверного приложения для сценариев веб-API: Серверная или управляющая программа для веб-API

Регистрация приложений

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

Срок действия маркера

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

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