Задать вопрос

Как корректно использовать пару JWT и Refresh токенов?

Как правильно организовать работу с парой токенов JWT + Refresh?

Суть: нужно добиться эффекта, что если пользователь пользуется системой, токены обновляются и все хорошо. Если пользователь отошел на час (время жизни access token), при дальнейшем действии его нужно разлогинивать из системы.
На текущий момент бэкенд полностью реализован, выдача токена, обновление, отзыв токена и тд. остаются следующие вопросы:
1) Кто следит за токеном и обновляет пару? Бэкенд или Фронтенд?
2) Я предполагал что фронтенд перед каждым запросом будет проверять не истек ли срок жизни access token, и если истек - отправляет запрос на обновление токенов, получает их, приклеивает и дальше проходит запрос. Но как в таком случае, разлогинивать пользователя при отсутствии активности в течении 1 часа?
  • Вопрос задан
  • 306 просмотров
Подписаться 5 Простой Комментировать
Решения вопроса 2
@calculator212
Я предполагал что фронтенд перед каждым запросом будет проверять не истек ли срок жизни access token, и если истек - отправляет запрос на обновление токенов, получает их, приклеивает и дальше проходит запрос. Но как в таком случае, разлогинивать пользователя при отсутствии активности в течении 1 часа?
Его не нужно разлогинивать, т.к. проверка токена не пройдет. В общем это будет примерно так выглядеть
1) фронт видит, что access токен истёк
2) Отправляет refresh на точку api
3) refresh api видит что refresh токен истёк и отправляет статус 401 например и фронт переводит пользователя на панель логина
4) пользователь вводит учётные данные снова
Ответ написан
Комментировать
@Kostik_1993
Web Developer
Время жизни access token ставите допустим 5 минут. Время жизни рефреша 1 час. Профит
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
Rsa97
@Rsa97
Для правильного вопроса надо знать половину ответа
Следить за сроком жизни может как клиент, так и сервер или оба.
В первом случае клиент, обнаружив просроченный токен доступа, сразу отправляет запрос на обновление. Недостаток - если на клиенте перевести часы назад, то он не обнаружит протухший токен.
Во втором случае время всегда берётся с одного источника (сервера), но будет лишний запрос, на который сервер ответит, что токен просрочен.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы