Использование библиотеки проверки подлинности Майкрософт для JavaScript для работы с Azure AD B2C

Important

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Чтобы узнать больше, пожалуйста, посмотрите "Технология Azure AD B2C все еще доступна для приобретения?" в нашем разделе часто задаваемых вопросов.

Библиотека проверки подлинности Майкрософт для JavaScript (MSAL.js) позволяет разработчикам JavaScript проходить проверку подлинности пользователей с помощью социальных и локальных удостоверений с помощью Azure Active Directory B2C (Azure AD B2C).

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

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

Поддерживаемые типы и сценарии приложений

MSAL.js позволяет одностраничным приложениям выполнять вход пользователей с помощью Azure AD B2C по потоку кода авторизации с PKCE. С помощью MSAL.js и Azure AD B2C:

Пользователи могут проходить проверку подлинности с помощью социальных удостоверений и локальных удостоверений.
Пользователи могут быть авторизованы для доступа к защищенным ресурсам Azure AD B2C (но не к защищенным ресурсам Microsoft Entra).
Пользователи не могут получить маркеры для API Microsoft (например, API MS Graph) с помощью делегированных разрешений.
Пользователи с правами администратора могут получать маркеры для API Microsoft (например, API MS Graph) с помощью делегированных разрешений.

Дополнительные сведения см. в статье "Работа с Azure AD B2C"

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

Следуйте инструкциям из руководства.

⚠️ Перед началом работы убедитесь, что вы узнаете, как инициализировать объект приложения и работать с ресурсами и областями. Мы также рекомендуем ознакомиться с Azure AD B2C. Дополнительные сведения см. в документации по B2C .

MSAL.js поддерживает аутентификацию с использованием социальных (Microsoft, Google, Facebook и т. д.), корпоративных (ADFS, Salesforce и т. д.) и локальных удостоверений (хранящихся в каталоге Azure AD B2C) с помощью Azure AD B2C (B2C сокращенно). При разработке приложений B2C с MSAL.jsследует учитывать несколько важных сведений.

Быстрые факты

Для B2C:

Пользователи могут проходить аутентификацию с помощью своих учетных записей в социальных сетях.
Пользователей можно авторизовать для доступа к ресурсам, защищенным B2C (но не к ресурсам, защищенным Microsoft Entra).
Пользователи не могут получать маркеры для API-интерфейсов Microsoft (например, MS API Graph) с помощью делегированных разрешений.
Приложения могут получать маркеры для MICROSOFT API с помощью разрешений приложений (сценарии управления пользователями).

Конфигурация приложений B2C

Ниже приведен пример конфигурации приложения B2C:

const msalConfig = {
  auth: {
    clientId: "<your-clientID>",
    authority: "https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/<your-policyID>",
    knownAuthorities: ["<your-tenant>.b2clogin.com"] // array of URIs that are known to be valid
  }
}

const apiConfig = {
  b2cScopes: ["https://<your-tenant>.onmicrosoft.com/<your-api>/<your-scope>"],
  webApiUri: "<your-api-uri>" // e.g. "https://fabrikamb2chello.azurewebsites.net/hello"
};

const loginRequest = {
  scopes: [ "openid", "offline_access" ]
}

const tokenRequest = {
  scopes: apiConfig.b2cScopes // e.g. "https://<your-tenant>.onmicrosoft.com/<your-api>/<your-scope>"
}

Microsoft Entra и конечные точки B2C

Основное различие между клиентами Microsoft Entra ID и Azure AD B2C заключается в их конечных точках.

Клиент Microsoft Entra ID:

Содержит только конечные точки Microsoft Entra (login.microsoftonline.com/*).
Предоставляет единую конечную точку токена (login.microsoftonline.com/.../token).
Конечные точки Microsoft Entra позволяют получать токены для:
- Ваши приложения, защищенные Microsoft Entra ID.
- Microsoft API, например MS API Graph.

Клиент B2C :

Содержит конечные точки Microsoft Entra ID и Azure AD B2C (login.microsoftonline.com/* и <your-domain>.b2clogin.com/*).
Предоставляет отдельные конечные точки токенов для каждого из них (login.microsoftonline.com/.../token, <your-domain>.b2clogin.com/.../token).
Конечные точки B2C позволяют получить токены для:
- Приложения, защищенные B2C.

B2C и делегированные разрешения

Делегированные разрешения определяют доступ на основе областей посредством интерактивной авторизации, выполняемой вошедшим в систему пользователем. Эти разрешения предъявляются ресурсу (например, ваш веб-API, API Microsoft Graph и т. д.) во время выполнения в виде scp утверждений в токене доступа клиента.

Аутентификация B2C пользователя не может использоваться для авторизации Microsoft Entra защищенных приложений или Microsoft API (которые также защищены Microsoft Entra ID). Таким образом, при использовании MSAL.jsнельзя использовать конечную точку <your-tenant>.b2clogin.com/.../token для получения маркера для MS API Graph.

Разрешения OpenID Connect

Исключение из приведенного выше правила происходит из специального набора областей, известных как разрешения OpenID Connect (OIDC), которые включают openid и profile. Другое специальное разрешение — это offline_accessразрешение, которое предоставляет приложению доступ к ресурсам от имени пользователя в течение длительного времени (с помощью маркера обновления). MSAL.js по умолчанию предоставляет openid, profile и offline_access при запросах loginPopup() и loginRedirect().

проверка подлинности Microsoft Entra для клиента B2C

Если вы используете конечную точку login.microsoftonline.com , не указывая параметры policyID для клиента B2C, вы обращаетесь к конечным точкам Microsoft Entra клиента B2C. Только в этом случае можно получить маркеры для ресурсов MS API Graph с помощью контекста пользователя, вошедшего в систему.

Разрешения B2C и приложения

Разрешения приложения указывают доступ на основе ролей с помощью учетных данных и удостоверений клиентского приложения. Эти разрешения предъявляются ресурсу во время выполнения в виде roles утверждений в токене доступа клиента.

Сценарии управления пользователями

login.microsoftonline.com Конечные точки по-прежнему можно использовать для любой фоновой неинтерактивной работы по управлению пользователями и атрибутами, даже если они предназначены специально для B2C. При создании регистрации приложения, которое будет использовать учетные данные клиента для управления ресурсами B2C с помощью MS API Graph, необходимо выбрать области API Graph, для получения разрешения для приложения управления (дополнительные сведения см. в документации). Помните:

Чтобы получить разрешения приложения, вам потребуется выполнить проверку подлинности приложения (с помощью предоставления учетных данных клиента).
Чтобы получить делегированные разрешения, необходимо выполнить проверку подлинности пользователя с учетной записью администратора.
Приложения управления обычно регистрируются в качестве типа аудитории 1 или типа 2 (см. ниже).

Другие разделы

B2C и типы учетных записей и аудиторий

Во время регистрации приложения вам будет предложено выбрать аудиторию. Выбранный вами тип аудитории определяет, на какой тип аутентификации вы ориентируетесь.

Тип аудитории	Description	Тип проверки подлинности
#1	Учетные записи в этом каталоге организации (только один клиент)	аутентификация Microsoft Entra
#2	Учетные записи в любом каталоге организации (мультитенантный).	аутентификация Microsoft Entra
#3	Учетные записи в любом каталоге организации или любом поставщике удостоверений	Аутентификация B2C

Получение маркера доступа для собственного API

Существует два способа получить маркер доступа для вашего API:

Запросите идентификатор клиента в качестве области:

msal.loginRedirect({
    scopes: ["client_Id"]
});

Дополнительные сведения см. здесь

Опубликуйте собственную область действия в регистрации вашего приложения и запросите эту область действия:

msal.loginRedirect({
    scopes: ["api://clientId/customScope.Read"]
});

B2C и процесс выхода из системы

Выход очищает состояние единого входа пользователя в Azure AD B2C, но пользователь может не выйти из сеанса у поставщика социальных удостоверений. Если пользователь выбирает тот же поставщик удостоверений во время последующего входа, он может повторно пройти проверку подлинности без ввода учетных данных. Здесь предполагается, что, если пользователь хочет выйти из приложения, это не обязательно означает, что они хотят выйти из своей социальной учетной записи (например , Facebook).

Поток B2C и поток приглашения

MSAL.js будет обрабатывать только те токены, которые он изначально запрашивал. Если в вашем сценарии необходимо отправить пользователю ссылку, которую он сможет использовать, чтобы зарегистрироваться, убедитесь, что эта ссылка ведет в ваше приложение, а не непосредственно на службу B2C. Пример потока приглашения выглядит следующим образом:

Пользователь щелкает ссылку на приложение
Приложение вызывает msal.loginRedirect и включает id_token_hint в extraQueryParameters

    msal.loginRedirect({
        scopes: ["example_scope"],
        extraQueryParameters: {'id_token_hint': your_id_token_hint}
    });

Приложение перенаправляется в службу B2C, где пользователь вводит учетные данные или регистрируется
Служба B2C перенаправляет обратно в ваше приложение, которое вызывает await msal.handleRedirectPromise() для обработки ответа и сохранения токенов

Использование B2C и iframe

Azure AD B2C предоставляет встроенную процедуру входа, которая позволяет отображать настраиваемый интерфейс входа в iframe. Так как MSAL запрещает перенаправление в iframe по умолчанию, необходимо задать для параметра конфигурации allowRedirectInIframeзначение true , чтобы использовать эту функцию. Дополнительные сведения об использовании iframe см. в статье "Использование MSAL в приложениях iframed"

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-07-02