Типы приложений, которые можно использовать в Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) поддерживает проверку подлинности для различных современных архитектур приложений. Все они основаны на стандартных отраслевых протоколах OAuth 2.0 или OpenID Connect. В этой статье описываются типы приложений, которые можно создавать независимо от предпочитаемого языка или платформы. Он также помогает понять высокоуровневые сценарии перед началом создания приложений.

Каждое приложение, использующее Azure AD B2C, должно быть зарегистрировано в клиенте Azure AD B2C с помощью портала Azure. Процесс регистрации приложения собирает и назначает значения, например:

• Идентификатор приложения, который однозначно идентифицирует приложение.
• URL-адрес ответа, который можно использовать для перенаправления ответов в приложение.

Каждый запрос, отправляемый в Azure AD B2C, указывает поток пользователя (встроенная политика) или настраиваемую политику , которая управляет поведением Azure AD B2C. Оба типа политик позволяют создавать высоко настраиваемый набор пользовательских возможностей.

Взаимодействие каждого приложения соответствует аналогичному шаблону высокого уровня:

1. Приложение направляет пользователя в конечную точку версии 2.0 для выполнения политики.
2. Пользователь завершает политику в соответствии с определением политики.
3. Приложение получает токен безопасности из конечной точки версии 2.0.
4. Приложение использует маркер безопасности для доступа к защищенной информации или защищенному ресурсу.
5. Сервер ресурсов проверяет маркер безопасности, чтобы убедиться, что доступ можно предоставить.
6. Приложение периодически обновляет маркер безопасности.

Эти шаги могут немного отличаться в зависимости от типа создаваемого приложения.

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

Для веб-приложений (включая .NET, PHP, Java, Ruby, Python и Node.js), размещенных на веб-сервере и доступных через браузер, Azure AD B2C поддерживает OpenID Connect для всех пользовательских возможностей. В реализации OpenID Connect в Azure AD B2C ваше веб-приложение запускает пользовательский опыт, отправляя запросы аутентификации в Microsoft Entra ID. Результатом запроса является id_token. Этот маркер безопасности представляет удостоверение пользователя. Он также предоставляет сведения о пользователе в виде утверждений:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "[email protected]",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Дополнительные сведения о типах маркеров и утверждений, доступных приложению, см. в справочнике по маркерам Azure AD B2C.

В веб-приложении каждое выполнение политики выполняет следующие высокоуровневые действия:

1. Пользователь переходит к веб-приложению.
2. Веб-приложение перенаправляет пользователя в Azure AD B2C, указывая политику для выполнения.
3. Пользователь завершает выполнение политики.
4. Azure AD B2C возвращает id_token в браузер.
5. id_token отправляется на URI перенаправления.
6. Проверяется и утверждается id_token, и устанавливается сеансовый файл cookie.
7. Безопасная страница возвращается пользователю.

id_token Проверка с помощью открытого ключа подписи, полученного от идентификатора Microsoft Entra ID, достаточно для проверки удостоверения пользователя. Этот процесс также задает файл cookie сеанса, который можно использовать для идентификации пользователя на последующих запросах страниц.

Чтобы увидеть этот сценарий в действии, воспользуйтесь одним из примеров кода входа в веб-приложение в разделе "Начало работы".

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

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

Многие современные веб-приложения создаются как клиентские одностраничные приложения (SPA). Разработчики пишут их с помощью JavaScript или платформы SPA, например Angular, Vue или React. Эти приложения выполняются в веб-браузере и имеют разные характеристики проверки подлинности, отличные от традиционных серверных веб-приложений.

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

Поток кода авторизации (с PKCE)

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

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

Чтобы воспользоваться этим потоком, приложение может использовать поддерживающую его библиотеку проверки подлинности, например MSAL.js 2.x.

Поток неявного предоставления

Некоторые библиотеки, такие как MSAL.js 1.x, поддерживают только неявный поток предоставления или ваше приложение реализовано с использованием неявного потока. В этих случаях Azure AD B2C поддерживает неявный поток OAuth 2.0. Неявный поток предоставления позволяет приложению получать ID токены и токены доступа. В отличие от потока кода авторизации, поток неявного предоставления доступа не возвращает маркер обновления.

Этот поток проверки подлинности не включает сценарии приложения, использующие кроссплатформенные платформы JavaScript, такие как Electron и React-Native. Эти сценарии требуют дополнительных возможностей для взаимодействия с собственными платформами.

Веб-API

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

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

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

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

1. Веб-приложение выполняет политику, а пользователь завершает процесс взаимодействия.
2. Azure AD B2C возвращает токен (OpenID Connect) id_token и код авторизации в браузер.
3. Браузер отправляет id_token и код авторизации в URI перенаправления.
4. Веб-сервер проверяет id_token и задает файл cookie сеанса.
5. Веб-сервер запрашивает у Azure AD B2C access_token, предоставив код авторизации, идентификатор клиента приложения и учетные данные клиента.
6. access_token и refresh_token возвращаются на веб-сервер.
7. Веб-API вызывается с заголовком авторизации access_token.
8. Веб-API проверяет маркер.
9. Безопасные данные возвращаются в веб-приложение.

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

Чтобы узнать, как защитить веб-API с помощью Azure AD B2C, ознакомьтесь с руководствами по веб-API в разделе "Начало работы".

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

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

В этом потоке приложение выполняет политики и получает authorization_code от Microsoft Entra ID после завершения выполнения политик. Представляет authorization_code разрешение приложения на вызов внутренних служб от имени пользователя, вошедшего в систему. Затем приложение может заменить authorization_code в фоновом режиме на access_token и refresh_token. Приложение может использовать access_token для аутентификации к серверному веб-API в HTTP-запросах. Он также может использовать refresh_token для получения нового access_token , когда срок действия более старой версии истекает.

Демоны/серверные приложения

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

Для Azure AD B2C поток учетных данных клиента OAuth 2.0 в настоящее время находится в общедоступной предварительной версии. Однако вы можете настроить поток учетных данных клиента с помощью идентификатора Microsoft Entra и конечной точки платформы /token удостоверений Майкрософт (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) для приложения Microsoft Graph или собственного приложения. Дополнительные сведения см. в справочной статье по токенам Microsoft Entra .

Неподдерживаемые типы приложений

Цепочки веб-API (от имени потока)

Многие архитектуры включают веб-API, который должен вызывать другой веб-API, причем оба защищены Azure AD B2C. Этот сценарий распространен среди локальных приложений, которые имеют серверную часть, работающую на веб-API, и используют онлайн-службы Microsoft, такие как Microsoft Graph API.

Этот сценарий веб-API может поддерживаться с помощью использования разрешения OAuth 2.0 JWT от имени другого лица, также известного как поток выполнения от имени. Однако поток от имени в настоящее время не реализован в Azure AD B2C.

Дальнейшие шаги

Узнайте больше о встроенных политиках, предоставляемых потоками пользователей в Azure Active Directory B2C.