@WotanWeb

Как правильно работать с JWT refresh-токеном?

Доброго дня, господа.
Прошу помощи, не могу разобраться с работой JWT-рефреш токенов.
Что понимаю на данный момент:
1 - пользователь авторизуется, в обмен на его логин/пароль ему отдаётся пара access token & refresh token
2 - на клиенте они пишутся в localStorage, и далее в каждом запросе передаются в хэдере
3 - пока access token не протух - всё хорошо.
4 - но что делать, если он протух?

Вот сервер получает refresh token и что он с ним должен сделать?
Предположим, я его записал в базу, прежде чем отдать клиенту, а сейчас сверил, соответствует, всё хорошо - генерирую новую пару и отдаю её в хэдере (что-то вроде set-new-jwt:xxxxxx)?

Или правильно отдать фронту ответ, что токен протух, а фронт бы запрашивал новый?

И ещё вопросы:
1) Как быть с несколькими устройствами при такой схеме? Получается, что пользователя разлогинит на неактивном устройстве?
2) Как инвалидировать токен? Просто чёрный список токенов (правильный ли это путь?)? Другого варианта, кроме как изменить секретный ключ, не вижу, но тогда разлогинит всех...

Заранее спасибо за помощь.
  • Вопрос задан
  • 226 просмотров
Пригласить эксперта
Ответы на вопрос 2
petermzg
@petermzg
Самый лучший программист
75638d5f8422f64a95cf2140f14c31a4.png
Из этой статьи
Ответ написан
Комментировать
@AleksRap
2 - на клиенте они пишутся в localStorage, и далее в каждом запросе передаются в хэдере


Нет, не в ls, а в стейте приложения

При правильном подходе JWT, это когда refreshToken присылается в httpOnly куке, к которой програмно ты не имеешь доступа ну никак. Плюс access токен в теле ответа.

В access токене зашифрована какая либо инфа, обычно время жизни и какие либо стартовые данные.
Вот время жизни и текущую дату ты уже пишешь в ls и при каждом запросе к серверу, перехватывая запрос проверяешь не истекло ли время жизни. Если истекло, то запрос отменяешь. А вместо него отправляешь запрос на рефреш (тут уже нужен рефреш токен, время жизни которого обычно гораздо больше чем у access, например 30дней против 1 дня) и после успешного рефреша посылаешь тот самый запрос, который был прерван

почему refresh только в httpOnly куке - Если он будет приходить в ответе с access токеном, то сразу две уязвимости: могут перехватить запрос и в нем получат сразу и access и refresh токены и спокойно зайдут в систему, либо своровать куки и access из приложения и опять же получить доступ ко всему

1) Как быть с несколькими устройствами при такой схеме? Получается, что пользователя разлогинит на неактивном устройстве?

Полагаю что так - один общий рефреш на все устройства и разные access токены. Таким образом можно отличать устройства юзера, какие залогинены, какие надо разлогинить
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы