Step‑Up Authentication vs 2FA: зачем нужен второй фактор внутри активной сессии
2026
Статья опубликована на Хабре у пользователя true_engineer. Она посвящена сравнению двух подходов к многофакторной аутентификации: классической 2FA, которая проверяет пользователя только при входе в систему, и Step-Up Authentication, запрашивающей дополнительное подтверждение личности уже внутри активной сессии при попытке выполнить критическую операцию. Автор объясняет, почему стандартной двухфакторной проверки на входе недостаточно в условиях современных атак, нацеленных на компрометацию уже существующих сессий, и в каких сценариях (доступ к зарплатным данным, работа с общего устройства, долгоживущие сессии) требуется повышение уровня доверия.
Ключевое техническое отличие Step-Up Authentication от 2FA — использование ACR (Authentication Context Class Reference) в токене, которое позволяет приложению проверять уровень аутентификации при каждом обращении к защищённому API. В проекте автора стандартный Identity Provider (WSO2) не смог покрыть бизнес-требования (шестимесячный срок действия PIN-кода, независимая проверка на уровне gateway), поэтому механизм был вынесен в отдельный микросервис PIN-кодов с собственной подписанной cookie, подтверждающей прохождение второго фактора.
Архитектурное решение включает gateway-2fa, который перехватывает только запросы к чувствительным ресурсам, проверяет наличие валидной cookie и при её отсутствии отклоняет доступ с кодом 401, предлагая пользователю ввести PIN-код. После успешной проверки cookie устанавливается с TTL 20 минут, и повторная аутентификация не требуется до её истечения. Для защиты от подмены выполняется сравнение полей JWT-токена пользователя с данными в cookie.
Автор приходит к выводу, что Step-Up Authentication становится архитектурным стандартом в парадигме Zero Trust, так как доверие к пользователю не должно сохраняться автоматически после входа. При внедрении важно учесть баланс TTL, надёжное хранение PIN-кодов, нагрузочное тестирование и логирование без раскрытия чувствительных данных. Опыт проекта показывает, что вынесение механизма в отдельный сервис даёт гибкость, независимость от IdP и точечную защиту критических операций без ухудшения пользовательского опыта.
Это краткая аннотация статьи, полную версию читайте в первоисточнике.
Первоисточник: Хабр (независимый автор), 2026
Эксперт: true_engineer, Хабр