Аутентификация и контроль доступа

Идентификация — заявление, кто вы (логин). Аутентификация — доказательство заявления (пароль, токен, биометрия). Авторизация — что личности разрешено (роли, права). Порядок: идентификация, аутентификация, авторизация действия.

JWT состоит из трёх частей в base64url через точку — header.payload.signature. Header задаёт алгоритм, payload хранит claims, signature вычисляется по первым двум. Обычный JWT подписан, но не зашифрован: payload читаем, обнаруживается лишь подмена.

Факторы — то, что вы знаете, чем владеете и чем являетесь. SMS слабее всех — код идёт через неподконтрольную сеть оператора и уязвим к подмене SIM. Одноразовый код выманивают в реальном времени; только WebAuthn привязан к origin сайта.

Детект: всплески неудачных входов по аккаунту (brute-force) или по многим (stuffing/spraying). Защита: throttling, CAPTCHA, запрет словарных паролей, MFA. Против enumeration — одинаковые ответы; новый сессионный токен при входе; cookie с SameSite и httpOnly.

Passkey — учётные данные на открытом ключе стандарта WebAuthn. Закрытый ключ не покидает устройство, на сервер идёт только открытый, поэтому нет общего секрета для утечки или воспроизведения. Браузер подписывает только для зарегистрированного origin.

Институт стандартов NIST требует длинного минимума, щедрого максимума и проверки пароля по спискам утечек. Правила состава символов и ротация по календарю не рекомендуются — они ведут к предсказуемым мутациям. Меняйте пароль по признаку компрометации.

Ролевая модель RBAC выдаёт права через именованные роли — их легко аудитировать, но роли множатся с каждым исключением. Атрибутная модель ABAC решает на каждый запрос по атрибутам пользователя, ресурса, действия и контекста. Обе по умолчанию запрещают.

Соль — уникальное случайное значение рядом с хэшем: одинаковые пароли дают разные хэши, и радужные таблицы бесполезны. Перец — секрет вне базы, поэтому украденный дамп плохо поддаётся перебору. Оба дополняют медленную KDF вроде Argon2id.

Идентификатор сессии должен быть длинным, из криптографического источника случайности, а не выведенным из логина, и выдаваться заново при входе. Отдавайте его в cookie с Secure, HttpOnly и SameSite, недоступной скриптам и чужим сайтам.

Главные риски — alg=none (неподписанный токен), путаница HS/RS, слабый HMAC-секрет, отсутствующий или безграничный exp, чувствительные данные в payload и доверие непроверенному kid. Защита: фиксировать алгоритм и exp, брать стойкие ключи.

Хранить JWT в cookie с httpOnly + secure или в памяти — не в localStorage, который читается любым JS, поэтому один XSS крадёт токен. Cookie с httpOnly недоступна JS, но шлётся автоматически, поэтому нужна защита от CSRF (SameSite). Важно: httpOnly/secure — атрибуты cookie, не localStorage.

Ссылка /restore/<id> с timestamp предсказуема — нужен случайный токен, одноразовый, с коротким TTL. Одинаковые ответы против перечисления; URL строить из конфигурации, а не из заголовка Host. Для OTP: лимиты отправок и вводов, TTL, лимит попыток.

Credential stuffing воспроизводит утёкшие пары по попытке на аккаунт, поэтому счётчики на аккаунт не срабатывают. Блокировка становится оружием: атакующий намеренно блокирует людей. Лучше плавное замедление, сигналы устройства и сети и MFA по риску.

Каждая SMS стоит денег, поэтому флуд запросов кода жжёт бюджет. Уберите SMS за первый фактор, чтобы анонимы её не вызывали; лучше push; лимитируйте запросы на пользователя/IP/устройство (особенно не введённые коды); выявляйте аномалии; ставьте WAF.

Восстановление — вторая дверь в аккаунт, поэтому система крепка ровно как её слабейший путь: сброс через почту отменяет ключ безопасности. Держите его на уровне основного входа: проверенные каналы, отложка с уведомлением перед сбросом MFA и аудит.

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

Дайте каждой нагрузке собственную проверяемую личность — сертификаты mTLS или короткоживущие токены от платформенного сервиса идентичности — вместо общего ключа API в конфиге. Учётные данные ротируются сами, узко ограничены и отзываются без передеплоя.

Нужны оба: таймаут бездействия закрывает забытую сессию, а абсолютный ограничивает срок жизни украденного токена. Инвалидируйте на сервере при выходе, сбросе пароля и смене прав, плюс выход со всех устройств. Токен без состояния живёт недолго.

Один провайдер идентичности стоит перед всеми, поэтому подделанное утверждение или взломанный админ достаёт до всех сразу. Ограничивают это MFA против фишинга у провайдера, короткие сроки утверждений, свои audience и scope на приложение и центральный отзыв.

Запускайте повышение фактора только на наборе чувствительных операций. Требуйте устойчивый к фишингу фактор там, где он зарегистрирован, иначе одноразовый код. Привязывайте результат к сессии и к этой конкретной операции на короткое окно, а не к глобальному флагу, и пишите в аудит субъекта, фактор и исход.