ХРАНЕНИЕ REFRESH ТОКЕНА

Несколько лет назад я делала краткий обзор аутентификации и авторизации. Про JWT и процесс создания/обновления токенов довольно понятно написано в стандарте. Также можно почитать подробные статьи на эту тему: 1, 2.

Сейчас хочется поговорить о работе с refresh-токенами: где их хранить на клиенте и нужно ли их хранить на сервере?

Давайте по порядку:

❓Где клиент хранит токены?

Наиболее важная задача для клиента — безопасно хранить и передавать refresh-token. Потому что именно этот токен может предоставить злоумышленникам долговременный доступ к ресурсам системы. Срок его жизни — это обычно дни или недели, к тому же, с его помощью можно получить новый refresh-token и так далее.

Обычно клиенты используют один из этих вариантов хранения:

• HttpOnly cookie — защищает от XSS, но уязвим к CSRF. Можно дополнительно создавать CSRF-токен, который хранится в переменной JS и передаётся в заголовке запроса. Так мы обеспечим защиту и от XSS, и от CSRF.
• LocalStorage / SessionStorage — удобно, но доступно любому JS-коду на странице.
• In-memory (переменная в JS) — безопасно, но теряется при обновлении страницы, поэтому там обычно хранят access-токен и CSRF-токен.


❓Где сервер хранит токены?

Access-токен живет в идеале до 15 минут и служит только для доступа к ресурсам, поэтому хранить на сервере его не нужно. А вот с refresh-токеном возможны разные варианты:

• Stateless (без хранения) — сервер ничего не хранит, только проверяет подпись. Вся нужная информация содержится в токене. Однако при таком подходе невозможно отозвать токен до истечения срока. Если токен украли — сделать ничего нельзя.
• Хранилище данных (Redis, СУБД) — позволяет отзывать токены, отслеживать сессии, реализовать ротацию. Очень важно хранить токены в захешированном виде.
• Гибридный вариант — stateless-токены плюс blacklist отозванных токенов в Redis/БД. Хранятся не все токены, а только те, что нужно инвалидировать.

❓Как безопасно хранить токены на сервере?

• Хеширование — refresh-токен это по сути пароль для получения access-токена. Поэтому его обязательно надо хешировать перед сохранением в хранилище.
• Ротация — при каждом обновлении токена клиент получает не только новый access, но и новый refresh-токен. Таким образом refresh чаще обновляется, а клиенту надо реже отправлять логин и пароль на сервер.
• Инвалидация старых токенов — старый refresh-токен помечается как отозванный сразу после выдачи нового. И если им кто-то еще раз попробует воспользоваться — это сигнал о возможной компрометации. После этого можно отозвать всё семейство токенов, вынудив пользователя войти заново.
• Хранение мета-информации — идентификатор устройства, срок действия, дата инвалидации, семейство токенов и пр.
Запоминая устройства, мы можем инвалидировать все устаревшие токены при перелогине на определенном устройстве.
При помощи даты инвалидации легче отслеживать попытки взлома аккаунта.
А семейтво токенов поможет определить, какие именно токены могли быть скомпроментированы.

✅ Как обычно, выбор способов хранения и обеспечения безопасности зависит от конкретики системы и требований:
Находится система в контуре компании или доступ открыт всему интернету?
Hасколько чувствительны данные?
Какие будут последствия компроментации?
Сколько стоит реализация и поддержка каждого этапа обработки refresh-токенов? И т.д.

А с какими вызовами вы сталкивались при реализации аутентификации?