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

Регистрация одностраничного приложения в Azure Active Directory B2C

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

Прежде чем приложения смогут взаимодействовать с Azure Active Directory B2C (Azure AD B2C), они должны быть зарегистрированы в управляемом клиенте. В этом руководстве показано, как зарегистрировать одностраничные приложения (SPA) с помощью портала Azure.

Обзор параметров проверки подлинности

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

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

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

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

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

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

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

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

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

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

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

Предпосылки

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

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.

  3. В портале Azure найдите и выберите Azure AD B2C.

  4. Выберите регистрации приложений и нажмите кнопку "Создать регистрацию".

  5. Введите имя приложения. Например, spaapp1.

  6. В разделе "Поддерживаемые типы учетных записей" выберите "Учетные записи" в любом поставщике удостоверений или каталоге организации (для проверки подлинности пользователей с помощью потоков пользователей)

  7. В разделе URI перенаправления выберите одностраничные приложения (SPA) и введите https://jwt.ms в текстовое поле URL-адреса.

    URI перенаправления — это конечная точка, куда сервер авторизации (Azure AD B2C, в данном случае) отправляет пользователя после завершения взаимодействия с ним. Кроме того, конечная точка URI перенаправления получает маркер доступа или код авторизации при успешной авторизации. В рабочем приложении обычно это общедоступная конечная точка, в которой работает приложение, например https://contoso.com/auth-response. В целях тестирования, например, в этом руководстве, вы можете использовать веб-приложение Майкрософт https://jwt.ms, которое отображает декодированное содержимое токена (содержимое токена никогда не покидает ваш браузер). В процессе разработки приложения вы можете добавить конечную точку, на которой приложение прослушивает локально, например, http://localhost:5000. URI перенаправления в зарегистрированных приложениях можно добавлять и изменять в любое время.

    На URI перенаправления налагаются следующие ограничения.

    • URL-адрес ответа должен начинаться со схемы https, если не используется localhost.
    • В URL-адресе ответа учитывается регистр. Его регистр должен соответствовать регистру URL-пути запущенного приложения. Например, если приложение включает в свой путь .../abc/response-oidc, не указывайте .../ABC/response-oidc в URL-адресе ответа. Поскольку веб-браузер обрабатывает пути с учетом регистра, файлы cookie, связанные с .../abc/response-oidc, могут быть исключены при перенаправлении на URL-адрес .../ABC/response-oidc, где не совпадает регистр.

  8. В разделе "Разрешения" установите флажок "Предоставить согласие администратора для разрешений openid и offline_access".

  9. Выберите Зарегистрировать.

Включение неявного потока предоставления

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

Чтобы включить поток неявного предоставления для приложения, выполните следующие действия.

  1. Выберите созданную регистрацию приложения.

  2. В разделе Управление выберите Проверка подлинности.

  3. В разделе "Неявное предоставление и гибридные потоки" установите флажки маркеров доступа (используемых для неявных потоков) и маркеров идентификатора (используемых для неявных и гибридных потоков).

  4. Нажмите кнопку "Сохранить".

Замечание

Если приложение использует MSAL.js версии 2.0 или более поздней версии, не включите неявный поток предоставления, так как MSAL.js 2.0+ поддерживает поток кода авторизации OAuth 2.0 (с PKCE). Если включить неявное предоставление для тестирования потока пользователя, убедитесь, что вы отключите параметры неявного потока предоставления перед развертыванием приложения в рабочей среде.

Миграция из неявного потока предоставления

Если у вас есть существующее приложение, использующее неявный поток, рекомендуется перенести поток кода авторизации с PKCE с помощью платформы, поддерживающей ее, например MSAL.js 2.0+.

Когда все рабочие SPA, представленные регистрацией приложения, начинают использовать поток кода авторизации, отключите параметры неявного потока предоставления, как показано ниже.

  1. В меню слева в разделе Управлениевыберите Проверка подлинности.
  2. В разделе "Неявное предоставление" снимите флажки "Токены доступа" и "Токены идентификатора".
  3. Нажмите кнопку "Сохранить".

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

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

Узнайте, как создать потоки пользователей в Azure Active Directory B2C.