👨‍💻 А вот собственно и сам веб-сервис: прокинул туннель через Cloudflare, есть вероятность, что файлы будут грузиться долго.

🎨 Это воплощение моего конвертера в вебе, есть ограничения, т.к. он хостится локально у меня.

🤏 Чуть больше тех. аспектов в следующем посте, а пока можете потестировать. Либо заддосить

P.s. статус активности: сервер выключен 🛑.

🔐 Refresh Token Rotation

👨‍💻 Расскажу вам немного про механизм ротации токенов. В моём проекте NetWalker есть пользователи и вся сопутствующая логика авторизации.

❓ Но как серверу понять, что юзер это действительно конкретный юзер?

🎫 Тут нам помогает JWT токен (access_token), который сервер генерирует на небольшое время. Как только время жизни истекает, токен становится невалидным и юзера по идее должно выкинуть из системы.

🤦‍♂️ Но мы же не хотим видеть, как каждые 10-15 минут приложение просит логиниться заново.

💀 Можно было бы забить и выдать access_token со сроком жизни на месяц, но если его перехватят или украдут, то злоумышленник получит полный доступ к аккаунту на этот самый месяц.

💡 Решение проблемы: связка с refresh токеном и его обязательная ротация.

⚙️ Как устроен этот механизм:
🔹 Помимо короткоживущего access_token, сервер генерирует долгоживущий refresh_token (например, на 30 дней) и сохраняет его в базу данных.
🔹 К обычным запросам клиент прикрепляет access_token. Сервер быстро проверяет подпись: если всё ок, запрос проходит дальше.
🔹 Когда у access_token заканчивается срок, клиент делает отдельный запрос на эндпоинт обновления.
🔹 Сервер сверяет пришедший refresh_token с записью в базе данных. Если всё сходится, значит, запрос пришёл от реального владельца.

🔄 В этот момент и происходит ротация: сервер генерирует совершенно новую пару access и refresh токенов, а старый рефреш токен сразу аннулирует.

👌 Для пользователя сессия продлевается бесшовно и незаметно.

🤔 Но тут возникает вопрос: а что если refresh_token всё-таки украли?

🛡 Вот здесь и раскрывается главная фишка ротации для безопасности (Token Reuse Detection).

🚨 Если кто-то попытается использовать уже отработанный или устаревший refresh_token, сервер сразу видит нестыковку. Это явный сигнал о краже или повторном использовании, поэтому сервер моментально рубит всю сессию (аннулирует всю цепочку токенов пользователя) и принудительно требует залогиниться заново.

📌 Полезные рекомендации на заметку:
- Хранить токены в HttpOnly cookies.
- refresh_token необязательно делать в формате JWT, это может быть просто криптографически стойкая случайная строка.
- В БД лучше сохранять только хэш от refresh_token, а не сам токен в чистом виде.
- Обязательно гонять весь трафик через HTTPS для защиты от атак типа Man-in-the-Middle (MitM).


👨‍💻 В следующем посте покажу уже свою реализацию из кода, где я чутка оптимизировал эту схему.

#образовач

⚙️ Реализация Refresh Token

📦 Для хранения сессии я использую класс UserSession (1). В нём лежит вся ключевая информация: хэш токена, данные об устройстве, статус сессии и т.д.

🔑 При регистрации или авторизации запрос уходит в UserSessionService, где метод CreateSessionAsync (2) генерирует первичную пару access и refresh токенов.

🚦 Дальше каждый входящий запрос обрабатывается отдельным middleware - TokenRefreshMiddleware (3).

💡 И здесь кроется отличие от прошлого поста. Там клиент сам ловит ошибку 401 и отправляет повторный запрос на рефреш с фронта. Я решил избавить фронтенд от этой рутины: middleware сам достаёт оба токена из cookies и проверяет их прямо на бэкенде.

🔄 Если access_token истёк, вызывается метод RefreshSessionAsync (4) у UserSessionService, который и запускает процесс ротации.

⚙️ Вся логика ротации разделена на три возможных исхода:

🚨 1. Invalid

Токен не подошёл ни под текущий хэш, ни под предыдущий. Тут же срабатывает Token Reuse Detection (детект повторного использования старого токена). Мы отзываем сессию и блокируем доступ, защищая аккаунт от взлома.

✅ 2. ValidCurrent

Стандартная успешная ротация. Текущий токен переносится в PreviousTokenHash, генерируется новый секрет и обновляется срок жизни сессии.

⏳ 3. ValidGracePeriod

Тот самый исход, о котором я не говорил в прошлый раз, но без которого на практике сессия сломается.

❓ Зачем нужен Grace Period?
Когда пользователь открывает страницу, браузер может одновременно отправить 3-4 параллельных запроса. Первый запрос прилетает на бэк, успешно ротирует токен и обновляет куку. Но остальные запросы уже находятся в пути, и у них всё ещё старый refresh токен.

💀 Без Grace Period сервер посчитал бы эти параллельные запросы атакой (Invalid), и пользователя бы просто выкинуло из системы на ровном месте.

🛡 Благодаря короткому окну (буквально пара секунд) бэкенд разрешает использовать старый токен из PreviousTokenHash и спокойно отдаёт данные, не ломая активную сессию.

👌 На этом механизм ротации завершён.

👾 Полезное наблюдение: генерировать refresh токен в формате <SessionId>.<Secret>. Это позволяет при проверке моментально находить сессию по Id, а затем сверять хэш секрета.

👨‍💻 Вышло завести OLED экранчик, запустил на нём Game of Life, хех.