Непрозрачные refresh-токены вместо JWT refresh
Целевой дизайн: refresh-токены — непрозрачные серверные записи, поэтому отзыв — это запись в БД, а не ожидание истечения. Access-токены короткоживущие, чтобы ограничить окно отзыва.
Кейс сервиса
Auth-сервис
Сервис учётных данных и сессий для демо-окружения: хранение секретов Argon2id, короткоживущие access-токены, непрозрачные ротируемые refresh-токены и обнаружение повторного использования.
ЗапланированРантайм бэкенда: Нет развёрнутого рантайма — стадия спецификацииИсточник данных демо: Mock
- Область применения
- Бэкенд-кейс о хранении учётных данных, жизненном цикле сессий, RBAC и rate limiting для демо-окружения zolotoy.dev.
- Не входит в область
- Не корпоративный IAM.
- Не социальный вход и не федеративная идентификация.
- Не универсальный OAuth-сервер авторизации.
- Инженерный фокус
- Жизненный цикл сессий, ротация и обнаружение повторного использования, RBAC, rate limiting.
Инженерный фокус
Жизненный цикл сессий, ротация и обнаружение повторного использования, RBAC, rate limiting.
Текущая реализация
Бэкенд-реализации пока нет. Демо-модуль отображает планируемые потоки на детерминированных моках; содержимое ниже — предлагаемая граница, а не работающая система.
- Current
Бэкенд-реализации пока нет: сервис на стадии спецификации и в демо представлен только детерминированными MSW-сценариями.
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
- Спецификация Auth-сервиса (целевой контракт)
Целевая архитектура
- Target
Хранение секретов Argon2id с солью на пользователя и подобранными параметрами стоимости; ответы логина устойчивы по времени к перебору учётных данных.
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
- Спецификация Auth-сервиса (целевой контракт)
- Target
Короткоживущие access-токены в памяти клиента; непрозрачные ротируемые refresh-токены в HttpOnly, Secure, SameSite cookie — никогда не в постоянном хранилище браузера.
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
- Спецификация Auth-сервиса (целевой контракт)
- Target
Ротация refresh с отзывом семейства сессий и обнаружением повторного использования: предъявление уже ротированного refresh-токена отзывает всё семейство.
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
- Спецификация Auth-сервиса (целевой контракт)
- Target
Роли user/admin, проверяемые на сервере, плюс rate limiting на эндпоинтах аутентификации и ограниченные ответы login/register.
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
- Спецификация Auth-сервиса (целевой контракт)
Архитектура / основной поток
- Демо в браузереAccess-токен только в памяти
- Auth-сервисВход, ротация refresh, сессии, RBAC
- Хранилище сессийНепрозрачные refresh-записи, семейства
- Order-сервисПроверяет access-токены; не хранит учётные данные
- refresh-cookie (HttpOnly, Secure): browser → auth (план)
- ротация + отзыв семейства: auth → store (план)
- Bearer access-токен: browser → order (план)
- introspection токена / общий JWKS — контракт TBD: order → auth (план)
Инженерные решения
Обнаружение повторного использования отзывает семейство сессий
Целевой дизайн: повторно предъявленный refresh-токен трактуется как признак кражи. Отзывается всё семейство сессий, принуждая к повторному входу на каждом устройстве семейства.
Устойчивость к перебору учётных данных — контракт на форму ответа
Целевой дизайн: одинаковый текст ответа, сопоставимое время и одинаковые коды статуса для «нет такого пользователя» и «неверный пароль» в login и сбросе пароля.
Надёжность / сценарии отказа
- Конкурентные refresh-запросы
- Несколько параллельных refresh с одним токеном: ротацию выигрывает ровно один; остальные должны переиспользовать результат координатора, а не ротировать снова и срабатывать на reuse detection.
- Повторно использованный refresh-токен
- Ротация при каждом использовании означает, что повтор токена — сигнал кражи: отозвать семейство сессий, отказать в refresh и вернуть отличимую ошибку, чтобы клиент форсировал повторный вход.
- Перебор учётных данных
- Ответы login/register/reset не должны раскрывать существование аккаунта — одинаковый текст, статус и близкий профиль времени, включая стоимость хэша для несуществующих пользователей.
- Политика при недоступности Redis
- План: поиск сессии должен безопасно деградировать (отказ или чтение из основного хранилища), а не работать в открытом режиме; rate limiting не должен тихо исчезать при недоступности Redis.
- Ограничения отзыва уже выпущенных JWT
- Access-токены нельзя отозвать до истечения; отзыв действует только на refresh. Короткий TTL access и серверные проверки сессии для чувствительных операций ограничивают экспозицию.
Доказательства
- Спецификация Auth-сервиса (целевой контракт)
docs/backend-specs/02_auth_service.mdzolotoy-dev-frontend (this repository)проверено 2026-09-17
Интерактивное демо
Следующая веха: Auth-сервис с живым фронтендом
Учётные данные, сессии, ротация refresh/обнаружение повторного использования, RBAC, cookies/CORS/CSRF и реальные браузерные сценарии с демо-фронтендом.
Критерии приёмки (план):
- Браузерный сценарий: регистрация → вход → ротация refresh → выход
- Повторное использование ротированного refresh-токена отзывает семейство сессий