🔐 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).


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

#образовач