Процесс аутентификации OAuth 2.0 и OIDC на идентифицирующей платформе Майкрософт

Для использования платформы удостоверений Майкрософт не требуется разбираться в OAuth или OpenID Connect (OIDC) на уровне протокола. Однако при использовании платформы управления идентификацией для добавления аутентификации в свои приложения вы столкнётесь с терминами и понятиями протоколов. При работе с центром администрирования Microsoft Entra, нашей документацией и библиотеками аутентификации знание некоторых основ поможет вам в интеграции и улучшит общий опыт работы.

Роли в OAuth 2.0

Четыре стороны обычно участвуют в проверке подлинности и обмене авторизацией OAuth 2.0 и OpenID Connect. Эти обмены часто называются потоками проверки подлинности или потоками проверки подлинности.

Скриншот схемы, показывающей роли в OAuth 2.0, включая сервер авторизации, клиента, владельца ресурса и сервер ресурсов

  • Сервер авторизации — платформа удостоверений Майкрософт является сервером авторизации. Он также называется поставщиком удостоверений (IdP) и безопасно обрабатывает информацию конечных пользователей, их доступ и отношения доверия между сторонами в потоке аутентификации. Сервер авторизации выдает маркеры безопасности, которые используются вашими приложениями и API для предоставления, отзыва или блокировки доступа к ресурсам (авторизация) после входа пользователя (аутентификация).

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

  • Владелец ресурса — владелец ресурса в потоке проверки подлинности обычно является пользователем приложения или конечным пользователем в терминологии OAuth. Конечный пользователь владеет защищенным ресурсом (их данными), к которому ваше приложение обращается от их имени. Владельцы ресурсов могут предоставить или запретить вашему приложению (клиенту) доступ к ресурсам, которыми они владеет. Например, приложение может вызвать внешний API системы для получения адреса электронной почты пользователя из профиля в такой системе. Данные профиля являются ресурсом, которым владеет конечный пользователь во внешней системе, и такой пользователь может утвердить или заблокировать запрос приложения на доступ к своим данным.

  • Сервер ресурсов — размещает данные владельца ресурсов или предоставляет доступ к ним. Чаще всего сервером ресурсов является веб-API с хранилищем данных. Сервер ресурсов использует сервер авторизации для аутентификации и использует сведения в маркерах носителя, выданных сервером авторизации, для предоставления или блокировки доступа к ресурсам.

Токены

Стороны в потоке аутентификации используют маркеры носителя для проверки и аутентификации субъекта (пользователя, узла или службы) и для предоставления либо блокировки доступа к защищенным ресурсам (авторизация). Токены носителя на платформе удостоверений Майкрософт имеют формат веб-токенов JSON (JWT).

Три типа маркеров носителя используются платформой удостоверений в качестве маркеров безопасности:

  • Маркеры доступа — маркер доступа выдается сервером авторизации клиентскому приложению. Клиент передает маркеры доступа серверу ресурсов. Маркеры доступа содержат разрешения, предоставляемые клиенту сервером авторизации.

  • Маркеры идентификатора — маркеры идентификатора выдаются сервером авторизации клиентскому приложению. Клиенты используют токены идентификации при аутентификации пользователей и для получения основных сведений о них.

  • Маркеры обновления — клиент использует маркер обновления (RT) для запроса новых маркеров доступа и идентификатора с сервера авторизации. Код должен рассматривать маркеры обновления и их строковое содержимое как конфиденциальные данные, так как они предназначены для использования только сервером авторизации.

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

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

Два из наиболее распространенных параметров регистрации приложений:

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

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

Конечные точки

Платформа удостоверений Майкрософт предоставляет службы аутентификации и авторизации с использованием соответствующих стандартам реализаций OAuth 2.0 и OpenID Connect (OIDC) 1.0. Серверы авторизации, соответствующие стандартам, такие как платформа идентификации, предоставляют набор HTTP-эндпоинтов, которые стороны процесса аутентификации используют для выполнения этого процесса.

URI конечной точки для приложения создаются автоматически при регистрации или настройке приложения. Конечные точки, используемые в коде приложения, зависят от типа приложения и удостоверений (типов учетных записей), которые оно должно поддерживать.

Две самых часто используемых конечных точки: конечная точка авторизации и конечная точка маркера. Ниже приведены примеры конечных точек authorize и token:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Чтобы найти конечные точки для зарегистрированного приложения, перейдите в Центр администрирования Microsoft Entra:

Entra ID>Регистрации приложений><YOUR-APPLICATION>>Точки подключения

Сводное описание всех конечных точек OIDC (обнаружение, авторизация, токен, UserInfo, JWKS, выход из системы) см. в разделе OpenID Connect на платформе удостоверений Майкрософт.

Следующие шаги

Далее вы узнаете о потоках аутентификации OAuth 2.0, используемых каждым типом приложения, и библиотеках, которые вы можете использовать в приложениях для их выполнения:

Мы настоятельно рекомендуем не создавать собственную библиотеку и не использовать прямые вызовы HTTP в потоках проверки подлинности. Microsoft Authentication Library безопаснее и проще в использовании. Однако, если ваш сценарий не позволяет использовать наши библиотеки или вы просто хотите узнать больше о реализации платформы удостоверений Майкрософт, у нас есть справочник по протоколу:

  • Last updated on