В этой статье мы обсудим сложную тему выбора правильного потока аутентификации (authentication flow) в зависимости от типа приложения и используемого сценария.

С точки зрения аутентификации в identity платформе Microsoft выделяются следующие типа приложений:

  • Single-page apps (SPA)
  • Web apps
  • Web APIs
  • Mobile apps
  • Native apps
  • Daemon apps
  • Server-side apps

Все приложения, кроме демонов, получают токен от имени пользователя. Если рассматривать с точки зрения сценария получения токена, то можно выделить следующие типы приложений:

  1. Одностраничные приложения (SPA). Чаще всего это frontend приложения, использующие JavaScript и фреймворки такие как Angular, React и Vue. Библиотека MSAL.js используется для аутентификации.
  2. Публичные клиенты. Это приложения всегда аутентифицируют пользователя. И здесь подразумеваются следующие сценарии:
    • Десктопные клиенты, которые вызывают API от имени пользователя
    • Мобильные клиенты
    • Приложения на устройствах, которые не имеют браузеры
  3. Конфиденциальные клиенты. Это приложения, которые используют секретный ключ клиента, чтобы аутентифицироваться:
    • Web apps или Web APIs , которые вызывают другие API, доступные в тенанте
    • Приложения-демоны, исполняемые как консольная служба.

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

Разные сценарии аутентификации доступны не для всех типов аккаунтов. Тип доступных аккаунтов называется Audience (аудитория). Среди них можно выделить:

  • Корпоративные аккаунты домена или тенанта
  • Персональные аккаунты Microsoft
  • Гостевые аккаунты (B2B и B2C)
  • Аккаунты приложений или SPN, зарегистрированные в тенанте.

Я попытался свести всю эту информацию воедино в одной таблице.

Таблица сценариев аутентификации в Azure AD

Тип
креденшелов
Тип
приложений и сценариев
Тип grant flowAudience
UserSPAAuthorization code с PKCETenant accounts, personal accounts, B2C
UserSPAImplicitTenant accounts, personal accounts, B2C
UserWeb app, который аутентифицирует пользователяAuthorization codeTenant accounts, personal accounts, B2C
UserWeb app, который вызывает APIAuthorization codeTenant accounts, personal accounts, B2C
UserDesktop приложение, которое вызывает APIИнтерактивный Authorization code с PKCETenant accounts, personal accounts, B2C
Встроенная Windows аутентификацияTenant accounts
Resource Owner Password Credentials (ROPC)Tenant accounts, B2C
UserПриложение без браузераDevice codeTenant accounts, personal accounts, B2C
UserМобильное приложение, которые вызывает Web APIИнтерактивный Authorization code с PKCETenant accounts, personal accounts, B2C
Client secretДемоны, которые вызывают APIClient credentialsAAD SPN в тенанте с application permissions
Web APIПриложение, которое вызывает другой Web APIOn-behalf-ofTenant accounts, personal accounts
Сравнение типов приложений и потоков авторизации

PKCE = Proof Key for Code Exchange — дополнительная безопасность для Authorization Code Flow, использует дополнительный секрет, который называется Code Verifier. Секрет создается при вызове приложения, который можно проверить сервером авторизации. Помимо этого вызывающее приложение создает трансформируемое значение Code Verifier, которое называется Code Challenge и посылает его по HTTPS, чтобы получить код авторизации. таким образом, перехваченный код авторизации использовать для обмена и получения токена не получится без Code Verifier.

В следующей статье мы подробнее рассмотрим основные типы grant flow и посмотрим как и где их использовать.

Насколько полезен этот пост?

Кликните на звезду, чтобы оценить!

Средний рейтинг 0 / 5. Количество голосов: 0

Еще нет голосов. Будь первым!

Поделиться:
Помечено %1$s , , , , ,

Написано автором Александр Д.