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

Использование протоколов OAuth 2.0 и OpenID Connect на платформе удостоверений Майкрософт

  • Статья

Знание 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:

Приложения> удостоверений>Регистрация приложений>< YOUR-APPLICATION>>Endpoints

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

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

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