ERP Platform Docs

ADR-001 Локальный JWT-фильтр вместо Auth Service на этапе MVP

время чтения ~2 мин.

ADR-001: Локальный JWT-фильтр вместо Auth Service на этапе MVP

Статус

Accepted

Контекст

Для реализации BR 1.1 (Юридические лица) нужны User Service и Store Service. Оба сервиса требуют авторизации запросов (JWT для public API, Service Token для internal API).

По архитектуре (System Overview) авторизацию обеспечивает Auth Service через POST /internal/auth/validate. Однако Auth Service зависит от User Service internal API (POST /internal/users/validate-credentials, GET /internal/users/by-email), а эти эндпоинты ещё не описаны в контрактах — нет BR по сотрудникам.

Возникает циклическая зависимость: Auth Service нужен User Service, а User Service нужен Auth Service для валидации JWT.

Рассмотренные варианты

  1. Локальный JWT-фильтр — каждый сервис сам парсит JWT (HS256 + shared JWT_SECRET). Auth Service не нужен для запуска.
  2. Сначала Auth Service — реализовать Auth Service + минимальные employee-эндпоинты в User Service. Затем остальные сервисы вызывают /internal/auth/validate.
  3. Мок Auth Service — заглушка, которая всегда возвращает valid: true.

Решение

Выбран Вариант 1: Локальный JWT-фильтр.

Каждый сервис содержит JwtAuthenticationFilter, который:

  • Извлекает JWT из заголовка Authorization: Bearer <token>
  • Валидирует подпись (HS256 + shared JWT_SECRET)
  • Извлекает claims: sub, role, franchise_id, store_ids, legal_entity_id
  • Устанавливает SecurityContext с данными пользователя

Для internal-эндпоинтов используется ServiceTokenFilter (проверка X-Service-Token).

Для тестирования JWT создаётся вручную (jwt.io или утилита) с нужными claims.

Последствия

Положительные

  • User Service и Store Service можно разрабатывать и запускать без Auth Service
  • Нет сетевого вызова на каждый запрос (быстрее)
  • Проще для разработки и тестирования

Отрицательные

  • JWT_SECRET должен быть одинаковым во всех сервисах (shared secret)
  • Нет централизованной инвалидации токенов (revoked токен будет валиден до истечения TTL)
  • При смене секрета нужно перезапустить все сервисы

Риски

  • При появлении Auth Service нужно будет решить: оставить локальный фильтр или перейти на централизованную валидацию. Миграция потребует обновления всех сервисов.

Условия пересмотра

Это решение будет пересмотрено когда:

  • Появится BR по сотрудникам (таблица employees, CRUD, авторизация)
  • Будет реализован Auth Service
  • Потребуется инвалидация токенов в реальном времени

Ссылки

Вид графа

Обратные ссылки