Выбор подхода проверки подлинности

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

Делегированная браузером проверка подлинности и собственная проверка подлинности — это два подхода к входу в Внешняя идентификация Microsoft Entra, которые определяют, как ваше приложение, работающее с клиентом, обрабатывает взаимодействие с проверкой подлинности. Оба подхода полностью поддерживаются, но они отличаются в пользовательском интерфейсе, усилиях разработки и модели безопасности. Понимание этих различий помогает выбрать подход, который лучше всего подходит вашему приложению.

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

При использовании native authentication вы создаете интерфейс пользовательского интерфейса входа непосредственно в приложение с помощью пакета SDK Microsoft Authentication Library (MSAL) или собственного API проверки подлинности. Пользователи никогда не покидают приложение. Вы управляете каждым аспектом пользовательского интерфейса, но ваша команда отвечает за создание и обслуживание интерфейса проверки подлинности.

Когда следует использовать делегированную браузером проверку подлинности

Делегированная браузером проверка подлинности лучше подходит при следующих случаях:

  • Ваше приложение может обрабатывать перенаправление браузера во время авторизации, не нарушая пользовательский опыт.
  • Вы предпочитаете меньшие затраты на реализацию и обслуживание. Microsoft автоматически управляет обновлениями системы безопасности и новыми функциями.
  • Вы хотите поддерживать самый широкий спектр платформ и языков с меньшим количеством кода.

Сведения о доступности определенных компонентов см. в сравнении функций.

Когда следует использовать собственную проверку подлинности

Родная аутентификация лучше подходит, когда:

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

Сведения о доступности определенных компонентов см. в сравнении функций.

Сравнение функций

В следующей таблице показано, какие функции доступны в каждом подходе.

Функция Делегированная браузером проверка подлинности Встроенная аутентификация
Регистрация и вход с помощью одноразового секретного кода электронной почты (OTP) ✔️ ✔️
Регистрация и вход с помощью электронной почты и пароля ✔️ ✔️
Вход с помощью электронной почты и пароля может использовать имя пользователя (псевдоним) и пароль ✔️ ✔️
Самостоятельный сброс пароля (SSPR) ✔️ ✔️
Поставщик пользовательских требований ✔️ ✔️
Многофакторная проверка подлинности с помощью однократного секретного кода электронной почты (OTP) ✔️ ✔️
Многофакторная проверка подлинности с помощью однократного секретного кода SMS (OTP) ✔️ ✔️
Аутентификация через поставщика социальной идентификации (Apple, Facebook и Google)1 ✔️ ✔️
Единый вход2 ✔️ ✔️

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

2 Нативная аутентификация поддерживает единый вход только для встроенных веб-интерфейсов. Единый вход между приложениями через системные браузеры недоступен с локальной аутентификацией.

Поддерживаемые языки и платформы

Для каждого подхода поддерживаются следующие языки и платформы.

Approach Поддерживаемые языки и платформы
Делегированная браузером проверка подлинности
  • ASP.NET Core
  • Android (Kotlin, Java)
  • iOS/macOS (Swift, Objective-C)
  • JavaScript
  • React
  • Angular
  • Node.js
  • Python
  • Java
Встроенная аутентификация
  • Android (Kotlin, Java)
  • iOS/macOS (Swift, Objective-C)
  • Web (JavaScript, React, Angular)
Для других языков и платформ можно использовать собственный API проверки подлинности.

Вопросы безопасности

Делегированная браузером проверка подлинности является более безопасным вариантом. Microsoft управляет поверхностью входа, что снижает вероятность фишинга и сбора учетных данных.

С помощью собственной проверки подлинности ваша команда разработчиков разделяет ответственность за безопасность с Microsoft Entra. Ваша команда должна следовать рекомендациям по обеспечению безопасности для обработки учетных данных пользователей. Прежде чем выбрать собственную проверку подлинности, обсудите последствия безопасности с владельцем вашего приложения и командой разработчиков.

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

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

Делегированная аутентификация через браузер:

Встроенная аутентификация:

  • Last updated on