Share via

Веб-интерфейс API

  • Статья

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

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

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

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

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

Схема

Схема

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

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

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

Делегированное удостоверение пользователя с OpenID Connect

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

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

  1. Пользователь уже вошел в веб-приложение, механизм проверки подлинности которого не зависит от Azure AD.
  2. Веб-приложению требуется код авторизации, чтобы получить маркер доступа. Поэтому оно отправляет запрос через браузер к конечной точке авторизации Azure AD, предоставляя идентификатор приложения и универсальный код ресурса (URI) перенаправления для веб-приложения после успешной аутентификации. Пользователь выполняет вход в Azure AD.
  3. Если пользователь веб-приложения еще не дал согласие на то, чтобы разрешить веб-приложению вызывать веб-интерфейс API от своего имени, пользователь должен дать такое согласие. Приложение отобразит разрешения, предоставление которых от него требуется, и, если любое из этих разрешений относится к уровню администратора, обычный пользователь в каталоге не сможет дать такое разрешение. Это разрешение применяется к однотенантным и мультитенантным приложениям. В случае с однотенантным приложением администратор может предоставить разрешение от имени своих пользователей. Это можно сделать с помощью кнопки Grant Permissions на портале Azure.
  4. После того как пользователь предоставит разрешения, веб-приложение получает код авторизации, необходимый для получения маркера доступа.
  5. Используя код авторизации, выданный Azure AD, веб-приложение отправляет запрос к конечной точке маркера Azure AD, которая содержит код авторизации, сведения о клиентском приложении (идентификатор приложения и универсальный код ресурса (URI) перенаправления) и требуемый ресурс (универсальный код ресурса (URI) идентификатора приложения для веб-API).
  6. Код авторизации, а также сведения о веб-приложении и веб-интерфейсе API проверяются системой Azure AD. После успешной проверки Azure AD возвращает два маркера: маркер доступа JWT и маркер обновления JWT.
  7. Веб-приложение использует возвращенный маркер доступа JWT, добавляя строку JWT с обозначением "Носитель" в заголовок авторизации запроса, отправляемого по протоколу HTTPS в веб-интерфейс API. Затем веб-интерфейс API проверяет этот маркер JWT, и, если проверка будет выполнена успешно, возвращает требуемый ресурс.

Примеры кода

Просмотрите примеры кода для сценариев "из веб-приложения в веб-интерфейс API". Регулярно возвращайтесь к этому разделу — мы часто добавляем новые примеры. Из веб-приложения к веб-интерфейсу API

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

Для регистрации приложения в конечной точке Azure AD v1.0 изучите раздел Регистрация приложения.

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

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

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

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