JWT авторизация в FastAPI: от теории до работающего кода

Полностью согласен, что ротация refresh-токенов с хранением jti в БД — это правильная основа для продакшена.

Несколько практических дополнений:

Гонка запросов. При параллельных вызовах /refresh  с одним токеном строгая одноразовость может привести к ложному логауту. Решается блокировкой в БД (SELECT FOR UPDATE SKIP LOCKED) и очередью на клиенте.

Нагрузка на БД. Ротация создаёт много операций записи. Активные токены лучше держать в Redis (с TTL), а PostgreSQL использовать для аудита и долгосрочной истории.

Управление сессиями. Добавление в таблицу refresh-токенов полей user_agent, ip, fingerprint позволяет пользователю видеть активные устройства и отзывать конкретные сессии.

Очистка. Redis сам удаляет истекшие записи. Для таблицы аудита нужен планировщик или партиционирование.

WebSocket. Если в приложении используются постоянные соединения, стоит продумать механизм переподключения с новым токеном без обрыва сессии.

Схема с ротацией хороша, но эти нюансы делают её готовой к реальным нагрузкам и сценариям использования.