Keeper

⚙️ Как работает:

1. Аутентификация по логину и паролю

• Пользователь проходит логин в одном из приложений, данные проверяются через Keycloak (grant_type=password)

• При успешном входе система:

  • Получает access_token

  • Расшифровывает sub — ID пользователя

  • Генерирует собственный краткоживущий ключ X-Auth-Key (аналог Яндекс.Ключа)

2. Выдача X-Auth-Key

   • Сервис создает уникальный ключ (например, UUID или JWT) и сохраняет его в Redis или базе с TTL (например, 1 час)

   • Ключ возвращается клиенту, хранится на устройстве

3. Авторизация через X-Auth-Key

   • При каждом запросе в любую часть экосистемы клиент передаёт X-Auth-Key в заголовке

   • API шлюз или backend-сервис валидирует его через собственный токен-сервис

   • При успешной проверке — доступ разрешён

4. Истечение срока действия ключа

   • Если ключ просрочен или невалиден, пользователь перенаправляется на логин по логину и паролю

5. Панель администратора

   • Через админ-интерфейс можно:

     • Сбросить пароль пользователя

     • Управлять ролями

     • Выпустить токен для сервисов (client_credentials)

     • Просматривать и отзывать X-Auth-Key (если хранится в БД)

🔐 Безопасность

• Все X-Auth-Key генерируются с ограниченным TTL и проверкой подписи/сохранением

• Токены пользователя (access_token, refresh_token) хранятся безопасно и никогда не передаются напрямую клиентам

• Поддерживается аудит действий, связанных с входом и управлением токенами

🧩 Интеграция в экосистему:

• Фронтенды получают X-Auth-Key при логине и используют его в запросах

• Backend-сервисы валидируют X-Auth-Key через внутренний токен-сервис

• Мобильные приложения работают через REST API с поддержкой автоматического продления ключа

📦 Стек:

• Keycloak (identity store)

• Redis (для хранения X-Auth-Key)

• FastAPI (обёртка над логикой авторизации и API шлюз)

🧩 Что делает Keycloak:

Что	Делает Keycloak?
Авторизация по логину/паролю	✅ Да
Выдаёт JWT токены	✅ Да
Управляет пользователями и ролями	✅ Да
Хранит токены в своей сессии	⚠️ Да, но не Redis
Генерирует кастомный внешний ключ (X-Auth-Key)	❌ Нет
Хранит X-Auth-Key с TTL и валидацией через ваш API	❌ Нет

✅ Зачем нужен X-Auth-Key, если есть токен?

1. Контроль и отзыв ключа со стороны бизнес-логики
   — Redis TTL, ручная деактивация, аудит.

2. Маскировка access_token от клиента
   — клиенту не выдаётся полноценный JWT токен, только ограниченный X-Auth-Key.

3. Унифицированный формат ключа для всей экосистемы
   — не важно, с какого сервиса вход: везде один формат, одна валидация.

4. Легко сделать key rotation и блокировку без влияния на Keycloak
   — без вмешательства в его токены и сессии.

🛠 Как это реализуется:

• Keycloak остаётся как identity provider — источник правды по пользователю.

• Ваш сервис (например, token-service) принимает access_token, валидирует его и создаёт X-Auth-Key, сохраняет его в Redis с TTL.

• Все остальные сервисы доверяют только X-Auth-Key, валидируя его через token-service.