В этой статье мы обсудим сложную тему выбора правильного потока аутентификации (authentication flow) в зависимости от типа приложения и используемого сценария.
С точки зрения аутентификации в identity платформе Microsoft выделяются следующие типа приложений:
- Single-page apps (SPA)
- Web apps
- Web APIs
- Mobile apps
- Native apps
- Daemon apps
- Server-side apps
Все приложения, кроме демонов, получают токен от имени пользователя. Если рассматривать с точки зрения сценария получения токена, то можно выделить следующие типы приложений:
- Одностраничные приложения (SPA). Чаще всего это frontend приложения, использующие JavaScript и фреймворки такие как Angular, React и Vue. Библиотека MSAL.js используется для аутентификации.
- Публичные клиенты. Это приложения всегда аутентифицируют пользователя. И здесь подразумеваются следующие сценарии:
- Десктопные клиенты, которые вызывают API от имени пользователя
- Мобильные клиенты
- Приложения на устройствах, которые не имеют браузеры
- Конфиденциальные клиенты. Это приложения, которые используют секретный ключ клиента, чтобы аутентифицироваться:
- Web apps или Web APIs , которые вызывают другие API, доступные в тенанте
- Приложения-демоны, исполняемые как консольная служба.
Все конфиденциальные клиенты могут использовать секреты клиента (симметричные общие секреты, созванные AAD) и учетные данные сертификата (асимметричные ключи, загруженные разработчиком). Для обеспечения максимальной безопасности рекомендуется использовать данные сертификата. Публичные клиенты (собственные приложения и SPA) не должны использовать секреты или сертификаты при задействовании кода авторизации.
Разные сценарии аутентификации доступны не для всех типов аккаунтов. Тип доступных аккаунтов называется Audience (аудитория). Среди них можно выделить:
- Корпоративные аккаунты домена или тенанта
- Персональные аккаунты Microsoft
- Гостевые аккаунты (B2B и B2C)
- Аккаунты приложений или SPN, зарегистрированные в тенанте.
Я попытался свести всю эту информацию воедино в одной таблице.
Таблица сценариев аутентификации в Azure AD
| Тип креденшелов | Тип приложений и сценариев | Тип grant flow | Audience |
|---|---|---|---|
| User | SPA | Authorization code с PKCE | Tenant accounts, personal accounts, B2C |
| User | SPA | Implicit | Tenant accounts, personal accounts, B2C |
| User | Web app, который аутентифицирует пользователя | Authorization code | Tenant accounts, personal accounts, B2C |
| User | Web app, который вызывает API | Authorization code | Tenant accounts, personal accounts, B2C |
| User | Desktop приложение, которое вызывает API | Интерактивный Authorization code с PKCE | Tenant accounts, personal accounts, B2C |
| Встроенная Windows аутентификация | Tenant accounts | ||
| Resource Owner Password Credentials (ROPC) | Tenant accounts, B2C | ||
| User | Приложение без браузера | Device code | Tenant accounts, personal accounts, B2C |
| User | Мобильное приложение, которые вызывает Web API | Интерактивный Authorization code с PKCE | Tenant accounts, personal accounts, B2C |
| Client secret | Демоны, которые вызывают API | Client credentials | AAD SPN в тенанте с application permissions |
| Web API | Приложение, которое вызывает другой Web API | On-behalf-of | Tenant accounts, personal accounts |
PKCE = Proof Key for Code Exchange — дополнительная безопасность для Authorization Code Flow, использует дополнительный секрет, который называется Code Verifier. Секрет создается при вызове приложения, который можно проверить сервером авторизации. Помимо этого вызывающее приложение создает трансформируемое значение Code Verifier, которое называется Code Challenge и посылает его по HTTPS, чтобы получить код авторизации. таким образом, перехваченный код авторизации использовать для обмена и получения токена не получится без Code Verifier.
В следующей статье мы подробнее рассмотрим основные типы grant flow и посмотрим как и где их использовать.
