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


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

Платформа удостоверений Майкрософт поддерживает проверку подлинности для различных современных архитектур приложений, все из них основаны на стандартных отраслевых протоколах 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": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Дополнительные сведения о различных типах маркеров в платформе удостоверений Майкрософт, см. в справочнике по маркерам доступа и в справочнике по 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, чтобы получить представление о компонентах протокола, используемых различными сценариями.