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

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

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

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

В каждом запросе, который отправляется в AAD B2C, указан поток пользователя (встроенная политика) или настраиваемая политика, которая управляет поведением AAD 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_token. Этот маркер безопасности представляет удостоверение пользователя. Кроме того, он содержит сведения о пользователе в форме утверждений.

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Все типы токенов и утверждений, доступных для приложения, описаны в справочнике 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. В рамках этого процесса также используется файл cookie сеанса, с помощью которого можно идентифицировать пользователя при последующих запросах страницы.

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

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

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

Многие современные веб-приложения создаются как клиентские одностраничные приложения. Разработчики пишут их с помощью JavaScript или платформы одностраничных приложений, например 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 для защиты таких веб-сервисов, как веб-интерфейс 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 возвращает браузеру маркер id_token (OpenID Connect) и код авторизации.
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 идентификатор после того, как пользователь завершит политику. 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 (поток On-Behalf-Of)

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

Этот сценарий веб-API с цепочками может поддерживаться путем предоставления учетных данных носителя JWT OAuth 2.0 или потока On-Behalf-Of. Однако в Azure AD B2C поток On-Behalf-Of еще не реализован.

Дальнейшие действия

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