Spec: user refresh JWT on auth_session (phase 2). Refs EventHub/EventHubBack#26

EventHubBackSpec.md

@@ -173,8 +173,8 @@ EventHub — платформа для управления событиями
 - Поддержка 100 000+ пользователей.
 - Горизонтальное масштабирование добавлением новых узлов.
 - Все персистентные таблицы хранятся в `disc_copies` на каждом узле (задача #13).
-- Сессионные таблицы: `auth_session` (единая модель refresh JWT) хранится в `disc_copies` для кластерной устойчивости.
+- Сессионные таблицы: `auth_session` (единая модель refresh JWT) в `disc_copies` для user и admin API.
-- Legacy-таблицы `session` и `admin_session` (`ram_copies`) сохранены для пользовательского `/v1/refresh` до фазы 2.
+- Legacy-таблицы `session` и `admin_session` (`ram_copies`) сохранены в схеме, user/admin hot path используют `auth_session`.
 - Индексы созданы для часто запрашиваемых полей (calendar_id, start_time, event_type, status и др.) (задача #13).
 - Полная репликация горячих таблиц между всеми узлами кластера (задача #14).
 - Автоматическое обнаружение узлов через DNS-имя `eventhub-node` или статический список (задача #14).
@@ -282,10 +282,10 @@ src/
 ### Общие принципы
 - Пользователи и администраторы используют разные эндпоинты и JWT-секреты.
 - Access-токен — короткоживущий stateless JWT (HS256).
-- Refresh-токен — 30 дней; для admin API реализован как подписанный JWT (фаза 1, #23).
+- Refresh-токен — 30 дней; подписанный JWT в единой session-модели (`auth_session`).
 - Все защищённые эндпоинты требуют заголовок `Authorization: Bearer <access_token>`.
 
-### Единая session-модель (`auth_session`, фаза 1 — admin)
+### Единая session-модель (`auth_session`)
 
 Таблица Mnesia `auth_session` (`disc_copies`):
 | Поле | Описание |
@@ -304,6 +304,12 @@ src/
 - `sid=<session_id>`, `fid=<family_id>`, `jti=<current_jti>`
 - `client=admin`, `exp`, `iat`
 
+**Refresh JWT (user, фаза 2)** — claims:
+- `typ=refresh`, `aud=user`, `sub=<user_id>`
+- `sid`, `fid`, `jti` — как у admin
+- `client=web` (фаза 3: `mobile`), `exp`, `iat`
+- Подпись: `JWT_SECRET` (user JWK), отдельно от admin
+
 **Поток login admin** (`POST /v1/admin/login`):
 1. Проверка email/password.
 2. Создание записи `auth_session`.
@@ -315,13 +321,23 @@ src/
 3. При совпадении — ротация: новый `jti`, новая пара токенов.
 4. При несовпадении (reuse) — `revoke_family`, ответ 401.
 
+**Поток login user** (`POST /v1/login`):
+1. Проверка email/password.
+2. Создание записи `auth_session` (`subject_type=user`, `client_type=web`).
+3. Ответ: `{ token, refresh_token, user }`.
+
+**Поток refresh user** (`POST /v1/refresh`):
+1. Верификация refresh JWT (`aud=user`).
+2. Сверка `jti` с `current_jti` в Mnesia, ротация при успехе.
+3. Reuse — `revoke_family`, 401.
+
 **Фазы внедрения:**
 - Фаза 1 (#23): admin API — реализовано.
-- Фаза 2: user `/v1/refresh` на той же модели.
+- Фаза 2 (#26): user login + `/v1/refresh` — реализовано.
-- Фаза 3: client web + mobile (тот же контракт `{token, refresh_token}`).
+- Фаза 3: client web + mobile (явный `client_type`, тот же контракт).
 
-### Legacy user refresh (до фазы 2)
+### Legacy (не используется login/refresh user)
-- `POST /v1/login` + `POST /v1/refresh` используют opaque refresh-токен в таблице `session` (`ram_copies`).
+- Таблица `session` (`ram_copies`) и opaque refresh в `core_session` — оставлены в кодовой базе, hot path user API переведён на `auth_session`.
 
 ## 7. ВЕРСИОНИРОВАНИЕ И СТАТУС
 Текущая версия: 1.5 (MVP, альфа). Включает: