Типы приложений для платформы удостоверений Майкрософт

Платформа удостоверений Майкрософт поддерживает проверку подлинности для различных современных архитектур приложений, все из них основаны на стандартных отраслевых протоколах OAuth 2.0 или OpenID Подключение. В этой статье описываются типы приложений, которые можно создавать с помощью платформы удостоверений Microsoft вне зависимости от выбранного языка и платформы. В ходе чтения вы получите общее представление о возможных сценариях. Затем можно приступать к работе с кодом в сценариях приложений.

Основные принципы

Необходимо зарегистрировать каждое приложение, использующее платформа удостоверений Майкрософт в центре администрирования Microsoft Entra Регистрация приложений. В процессе регистрации приложения будет задано несколько параметров приложения:

  • ИД приложения (клиента), идентифицирующий ваше приложение уникальным образом
  • универсальный код ресурса (URI) перенаправления, который можно использовать для направления ответов к приложению;
  • Несколько других значений, относящихся к сценарию, например поддерживаемые типы учетных записей

Дополнительные сведения см. в статье о регистрации приложения.

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

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Типы приложений, поддерживаемые платформа удостоверений Майкрософт;

  • Одностраничные (SPA)
  • Веб-приложение
  • Веб-интерфейс API
  • Мобильные и собственные приложения
  • Служба, управляющая программа, скрипт

Одностраничные приложения

Многие современные приложения имеют интерфейсное приложение с одной страницей (SPA), написанное в основном на JavaScript, часто с платформой, такой как Angular, React или Vue. Платформа удостоверений Майкрософт поддерживает эти приложения с помощью протокола OpenID Подключение для проверки подлинности и одного из двух типов грантов авторизации, определенных OAuth 2.0. Поддерживаемые типы грантов — это поток неявного предоставления OAuth 2.0 или более поздний код авторизации OAuth 2.0 + поток PKCE (см. ниже).

Схема потока демонстрирует поток предоставления кода авторизации OAuth 2.0 (с сведениями о PKCE опущен), где приложение получает код из конечной точки платформа удостоверений Майкрософт authorize и активирует его для маркера доступа и маркера обновления с помощью межсайтовых веб-запросов. Для spAs маркер доступа действителен в течение 1 часа и после истечения срока действия должен запросить другой код с помощью маркера обновления. Он, как и маркер доступа, id_token, представляющий вошедшего в систему пользователя для клиентского приложения, обычно запрашивается с помощью этого же потока и/или отдельного запроса OpenID Connect (здесь не показан).

Схема, на которой показан поток кода авторизации OAuth 2.0 между одностраничным приложением и конечной точкой службы маркеров безопасности.

Чтобы увидеть это в действии, ознакомьтесь с кратким руководством. Войдите пользователей в одностраничные приложения (SPA) и вызовите API Microsoft Graph с помощью JavaScript.

Поток кода авторизации и неявный поток

Поток кода авторизации OAuth 2.0 теперь — это рекомендуемый способ создания spAs для обеспечения совместимости приложения в Safari и других браузерах, ориентированных на конфиденциальность. После удаления сторонних файлов cookie и большего внимания не рекомендуется использовать неявный поток.

Веб-приложения

Для веб-приложений (.NET, PHP, Java, Ruby, Python, Node), доступных пользователю через браузер, для входа пользователей можно использовать OpenID Connect. В OpenID Connect веб-приложение получает маркер идентификации. Это маркер безопасности, который проверяет удостоверение пользователя и предоставляет сведения о пользователе в форме утверждений.

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "ab12cd34-effe-5678-9012-abcdef012345"
    ...
}

Дополнительные сведения о различных типах маркеров в платформе удостоверений Майкрософт, см. в справочнике по маркерам доступа и в справочнике по id_token.

В приложениях веб-сервера поток аутентификации для входа состоит из следующих базовых этапов.

Показывает поток проверки подлинности в веб-приложении

Личность пользователя можно подтвердить, проверив маркер идентификации с открытым ключом подписывания, полученным от платформы удостоверений Майкрософт. Для этого задается файл cookie сеанса, с помощью которого можно идентифицировать пользователя при последующих запросах страницы.

Узнайте больше, создав веб-приложение ASP.NET Core, которое входит в систему пользователей в следующей серии учебников с несколькими частью

Помимо простого входа, приложению веб-сервера может потребоваться доступ к другой веб-службе, например API передачи репрезентативного состояния (REST). В этом случае приложение веб-сервера участвует в объединенном потоке OpenID Connect и OAuth 2.0 с использованием потока кода авторизации OAuth 2.0. Дополнительные сведения об этом сценарии см. в нашем примере кода.

Веб-API

Платформу удостоверений Майкрософт можно использовать для защиты веб-служб, таких как веб-API RESTful вашего приложения. Веб-API можно реализовать на множестве платформ и языков. Их также можно реализовать с помощью триггеров HTTP в функциях Azure. Веб-API вместо маркеров идентификации и файлов cookie сеанса использует маркер доступа OAuth 2.0 для защиты данных и аутентификации входящих запросов.

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

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
Accept: application/json
...

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

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

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

Показывает поток проверки подлинности в веб-API

Чтобы узнать, как защитить веб-API с помощью маркеров доступа OAuth2, проверка примеры кода веб-API в руководстве по защищенному веб-API.

Во многих случаях веб-интерфейсам API также требуется выполнять исходящие запросы к другим нижестоящим веб-API, защищенным платформой удостоверений Microsoft. Для этого веб-API могут воспользоваться потоком On-Behalf-Of (OBO), который позволяет веб-API обменивать входящие маркеры доступа для использования другого маркера доступа в исходящих запросах. Дополнительные сведения см. в разделе Платформа удостоверений Майкрософт и поток On-Behalf-Of в OAuth 2.0.

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

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

В этом потоке приложение при входе пользователя в систему получает код авторизации от платформы удостоверений Майкрософт. Код авторизации представляет собой разрешение, полученное от приложения, на вызов внутренних служб от имени пользователя, выполнившего вход. Приложение может передать код авторизации в фоновом режиме, чтобы получить маркер доступа OAuth 2.0 и маркер обновления. Приложение может использовать маркер доступа для аутентификации в интерфейсах веб-API в HTTP-запросах и использовать маркер обновления, чтобы получать новые маркеры доступа после истечения срока действия старых маркеров.

Показывает поток аутентификации собственного приложения

Примечание.

Если приложение использует системное представление по умолчанию, проверка сведения о функциях "Подтверждение входа" и коде AADSTS50199 ошибки в коде ошибок проверки подлинности и авторизации Microsoft Entra.

Серверные, daemons и скрипты

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

В этом потоке приложение взаимодействует непосредственно с конечной точкой /token, чтобы получить доступ:

Показывает поток аутентификации управляющей программы

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

См. также

Теперь, когда вы знакомы с типами приложений, поддерживаемыми платформой удостоверений Microsoft, узнайте больше о OAuth 2.0 и OpenID Connect, чтобы получить представление о компонентах протокола, используемых различными сценариями.