Современная аутентификация: passkeys, OIDC, сессии — настоящий краткий список

Безопасность и доверие Jul 11, 2026 at 17:195В закладки

Популярный тред на Hacker News снова поднимает вопрос: как следует аутентифицировать приложение в 2026 году? Ответ больше не «JWT + refresh token». Обзор без прикрас.

Простыми словами

В 2026 году «правильный» способ аутентификации веб-приложения зависит от двух вопросов: (1) вы — это B2C-приложение для массового пользователя или B2B SaaS? (2) вы готовы управлять собственным IdP или доверяетесь провайдеру? Шаблоны середины 2020-х (JWT без состояния + refresh в localStorage) устарели — и не без причины.

Суть дела

Хабра-пост возвращается к классической дискуссии и приходит к интересной конвергенции: для большинства приложений прагматичный стек 2026 года выглядит так:

Серверная сессия в зашифрованном HttpOnly-куке с SameSite=Lax для состояния аутентификации. Хватит JWT на клиенте.
OIDC (Google/Apple/GitHub) для бесшовного входа без пароля.
Passkeys (WebAuthn) для второго этапа или полной замены пароля. Теперь повсеместно поддерживается (iOS 17+, Android 13+, все браузеры).
Короткая ротация серверной сессии (~1ч) + долгий refresh (~14 дней) через отдельный куки.
Нет JWT на клиенте, кроме случаев, когда нужен реальный stateless multi-tenant.

Что изменилось структурно — три вещи. Во-первых: конец использования localStorage для чувствительных токенов (XSS = полная компрометация, здесь больше нет споров). Во-вторых: зрелость passkeys — массовая поддержка превысила критическую отметку в основных экосистемах (Google, Apple, Microsoft развернули всё, хотя ни один не опубликовал свежих детальных цифр). В-третьих: хостинговые IdP (Clerk, WorkOS, Auth0) теперь предлагают коробочное решение для SSO/SCIM/passkeys, которое не стоит пересобирать командам менее 5 человек.

Под капотом

Куки сессии: Secure; HttpOnly; SameSite=Lax; префикс __Host-. Ротация при каждом повышении привилегий.
CSRF: SameSite=Lax покрывает 95% случаев; добавление CSRF-токена на чувствительные мутации остаётся страховочным поясом.
PKCE обязателен для всех публичных OAuth-процессов (SPA, мобильные).
Распространённая ловушка: слишком раннее принудительное использование passkey как единственного 2FA — потеря аккаунта, если у пользователя только одно устройство.
Модная уязвимость: расширения браузера, читающие память SPA — ещё один аргумент не хранить ничего в localStorage.

Что делать

Три вывода. Во-первых: если вы стартуете в 2026 году, берите провайдера (Clerk, WorkOS, Stack Auth), кроме случаев строгих регуляторных требований. Сэкономленное инженерное время уйдёт в продукт. Во-вторых: если у вас legacy-стек с JWT в localStorage, планируйте миграцию на куки сессии — это приоритетная задача безопасности, а не косметическая. В-третьих: passkeys готовы; можно включать их как опцию сейчас и делать обязательными к 2027 году в enterprise. Следите за стандартизацией passkeys между платформами (это реальное ограничение для B2B).