Appearance
Безопасность аккаунта: что доступно вашим пользователям
Обзор встроенных в SSO средств защиты аккаунта — полезно знать, что уже есть у платформы, прежде чем встраивать собственные механизмы безопасности поверх неё, и чтобы объяснять пользователям, что означают экраны, которые они увидят при входе через ваше приложение. Все настройки — на стороне SSO, в /account/security; вашему приложению для этого ничего дополнительно реализовывать не нужно.
Двухфакторная аутентификация (2FA / TOTP)
Стандартный второй фактор — приложение-аутентификатор (Google Authenticator, Authy и подобные). При включении пользователю выдаётся набор одноразовых резервных кодов на случай утраты устройства с приложением — их стоит сохранить в надёжном месте сразу при получении, повторно они не показываются.
MFA по email
Одноразовый код, присылаемый на почту, — независимая альтернатива приложению-аутентификатору. Полезно как запасной вариант или как более простой первый шаг для пользователей, которым неудобно ставить отдельное приложение. Действует ограниченное время и одноразово.
Аппаратные ключи и Passkeys (WebAuthn / FIDO2)
Два родственных, но разных механизма:
- Passkeys — вход по биометрии устройства (Face ID, Touch ID, Windows Hello), без физического ключа.
- Аппаратные ключи — физические USB/NFC-ключи (например, YubiKey).
Оба варианта требуют защищённого соединения (https://, либо localhost при локальной разработке) — на голом IP-адресе без TLS работать не будут.
Adaptive MFA
Отдельная персональная настройка, по умолчанию выключенная. Идея: устройство, с которого пользователь уже когда-то успешно проходил проверку второго фактора, обычно не требует его заново — это снижает трение при частых входах. При включённом Adaptive MFA это доверие перестаёт быть безусловным: если вход выглядит необычно (см. ниже), второй фактор запрашивается повторно даже с уже знакомого устройства.
Уровни риска входа
Каждая попытка входа оценивается по совокупности сигналов — знакомо ли устройство и браузер, типична ли сеть, из которой пришёл запрос, правдоподобна ли смена местоположения по сравнению с предыдущим входом. Итоговая оценка сводится к одному из трёх уровней:
| Уровень | Что происходит |
|---|---|
| Низкий | Обычный вход. На знакомом устройстве MFA может не запрашиваться повторно |
| Средний | При включённом Adaptive MFA — второй фактор запрашивается даже на знакомом устройстве |
| Высокий | Второй фактор запрашивается обязательно; для пользователей без включённого MFA вход может быть заблокирован полностью |
Конкретные веса и пороговые значения, по которым считается уровень, не публикуются — это часть защитного механизма, а не документация по конфигурации. Для эксплуатации на вашей стороне важно знать три вещи: пользователю без включённого MFA при подозрительном входе может быть отказано в доступе; это ожидаемое поведение, а не сбой интеграции; пользователю стоит порекомендовать включить любой второй фактор, если он регулярно с этим сталкивается.
Уведомления о подозрительном входе
Отдельная опциональная настройка — пользователь может включить себе уведомления на почту о случаях, когда вход был заблокирован или потребовал повторного прохождения MFA из-за повышенного риска. Полезно порекомендовать пользователям включить эту опцию, если для вашего приложения важна видимость подозрительной активности на их стороне.
Подключённые приложения
Пользователь видит список приложений, которым он выдал согласие на вход через SSO, на отдельной странице своего аккаунта — включая ваше приложение, под тем названием, логотипом и ссылкой на сайт, которые вы указали при регистрации клиента (см. 02-client.md). Там же пользователь может в любой момент самостоятельно отозвать доступ вашему приложению — если это произошло, все выданные ему токены для этого пользователя перестают быть действительными, и ему потребуется пройти согласие заново. Учитывайте это в своей логике обработки ошибок авторизации: отозванный доступ выглядит так же, как истёкший refresh_token (invalid_grant).