Авторизация в веб-продуктах: сессии, токены и политики доступа без боли

Авторизация пользователей сайта — это не выбор «JWT или сессии». Это проектирование доверенных границ, сроков жизни идентичности, политик доступа и наблюдаемости. Мы строим аутентификацию как отдельный домен: Sign-In/Up/Out, восстановление, привязки соц-провайдеров, SSO OIDC интеграция, MFA/пароли-приложения. На стороне авторизации — RBAC роли и права, а также атрибутные политики (ABAC) для гибкости. Ниже — наш инженерный стандарт и анти-паттерны, которые мы встречали на реальных проектах.

1) Сессии vs JWT: где чему место

Сессионные куки хорошо подходят для веб-клиентов: короткий токен в HttpOnly куке, флагиSecure, SameSite, сервер хранит состояние/«ревоки». JWT удобен как переносной маркер для API-клиентов/мобилок/микросервисов. Мы часто комбинируем: в браузере — сессии, для API/интеграций — подписанные короткоживущие JWT, обновляемые по рефреш-токену. Главный принцип — минимальные срок и объём прав для каждого маркера (PoLP).

• Сессия: отзыв и logout выполняются централизованно; защита от XSS — за счёт HttpOnly.
• JWT: статлесс-верификация и масштабирование; но отзыв требует списков блокировок/короткой жизни.
• Рефреш-токены — только в защищённых хранилищах (сервер/куки), вращение при каждом обновлении (rotation).

2) OAuth2/OIDC и SSO: делегирование идентичности

Для корпоративных продуктов мы поднимаем провайдер с OpenID Connect, поддерживаем Federation (Google/Microsoft/ADFS). Сценарий: редирект на авторизацию → короткоживущий код → обмен на токены на сервере → установка сессии. PII и токены не попадут в клиентский JS. Для мультиорганизаций — «организация по домену», привязка ролей и групп через маппинг клеймов.

Практические правила

• Используйте PKCE и Authorization Code для SPAs с серверным обменом.
• Храните рефреш-токен только на сервере (BFF-слой), а не в localStorage.
• Проверяйте nonce/state, аудитируйте истечения и неуспешные попытки входа.

3) RBAC/ABAC: роли, права и контекст

Роли описывают «кто» (админ, менеджер, аналитик), права — «что можно» (просмотр, редактирование, экспорт).RBAC прост и прозрачен. ABAC добавляет контекст: «можно редактировать только свои объекты», «только в рабочем часу». Мы комбинируем: RBAC для базовых прав, ABAC — для условий. Политики формализуем как декларативные правила, которые одинаково выполняются в сервере и, частично, на клиенте (для «оптимистичных» состояний UI).

Гайд по контролю доступа

• Права описываются примитивами: read/write/delete/export на домены.
• Запрещения сильнее разрешений; журнал решений — для аудита «почему отказано».
• Проверка доступа — на сервере; клиент лишь скрывает недоступные действия.

4) Пароли, MFA и «безопасный UX»

Пароли храним только хэшами (современные алгоритмы с солью и адаптивной сложностью), блокируем брутфорс по IP/аккаунту, предлагаем вход по почте/маг-ссылке и TOTP/WebAuthn. UX не раскрывает, существует ли аккаунт («если почта есть — мы отправили ссылку»). Сброс пароля — одноразовый токен с коротким TTL и журналом использования.

5) Сроки жизни, ротация и отзыв

Access-токен — минуты, рефреш — дни/недели с ротацией и отзывом при аномалии. Сессии — «скользящие» с ограничением абсолютного TTL. Отзыв выполняется по списку «сгоревших» рефрешей/сессий; при компрометации — тотальная ротация ключей подписи и глобальный логаут.

6) BFF-подход: меньше секретов в клиенте

Backend-for-Frontend выдаёт браузеру только сессию, а сам ходит к провайдерам идентичности/ресурсам с сервера. Так упрощается CORS, скрываются токены, вводятся централизованные лимиты/аудит. Мы предпочитаем BFF для публичных SPA/SSR-продуктов.

7) Наблюдаемость и журналирование

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

8) Анти-паттерны

• Хранить токены в localStorage — XSS заберёт их первым.
• JWT «навсегда» без отзыва — потеряли контроль над доступом.
• Проверять права только на клиенте — уязвимость к подмене запросов.
• Смешивать роли и UI-флаги — хаос и непредсказуемость.

Итог: надёжная аутентификация — это сессии/токены с малыми TTL, SSO OIDC интеграция для корпоративных сценариев и строгие политики RBAC/ABAC. Мы строим доступ так, чтобы им было удобно управлять, а продукт оставался защищённым. Сроки/стоимость внедрения уточняйте по контактам на сайте.