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

Собственные приложения

  • Статья

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

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

Собственное приложение вызывает веб-API от имени пользователя. Этот сценарий построен на основе типа предоставления кода авторизации OAuth 2.0 с общедоступным клиентом, как описано в разделе 4.1 в документе Спецификация OAuth 2.0. Нативное приложение получает маркер доступа для пользователя с помощью протокола OAuth 2.0. Затем этот маркер передается в запросе к веб-интерфейсу API, который авторизует пользователя и возвращает нужный ресурс.

Схема

Схема

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

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

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

Примечание

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

Примеры кода

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

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

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

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

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

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

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