Как на клиенте определить время жизни токена JWT?

Question

[Sport-code]

Всем привет!

Подскажите пожалуйста, как на клиенте определить время жизни токена (JWT-token и JWT-passport), если закончилось время, я его храню в localstorage?
У меня интернет магазин все товары загружаю во Vuex при загрузке сайта, т.е. к серверу обращаюсь один раз.
Я никак не могу сообразить как бы правильно проверить токен, если я не обращаюсь к серверу.
Если время закончилось, то его нужно удалить.

Comments

[alex]

не надо ничего проверять на клиенте. если нужно проверить токен делайте пинг на сервер.

[Александр Дроздов]

Alex правильно сказал, считай что клиент это самое небезопасное место которое может быть)

[Sport-code]

Alex,
А можно, если не за труднит примерчик, что за пинг и куда его вставить (в click или в хук или еще куда-то)
И как часто пинг посылать?
Спасибо

[alex]

Sport-code, ну делаете метод апи, типо - site.com/api/auth/ping, и на этот эндпоинт делаете запрос, а он обратно 204 если все ок или 401 если токен протух. это как один из многих вариантов как можно это реализовать. запрос можно по интервалу посылать. можно лонгполинг или вебсокеты вообще применит, наверное, я не пробовал.

[Sport-code]

У меня метод Login генерирует токен на 15 мин. и в интерцеторе я добавляю Authorization, со стороны сервера все нормально, и когда expirate то возвращается 401.
Если запрос router.beforeEach как использовать или watch, можно как-то?

[Sport-code]

Честно, я так и не понял как правильно сделать?!
Хорошо, если на клиенте, то мне нужно сделать примерно так
от текущей даты сравнить EXP ?

[alex]

Честно, я так и не понял как правильно сделать?!

сравниваете exp с Date.now(). если exp меньше или равен .now() значит токен протух. плюс нужно будет сделать поправку на часоывае пояяса наверное.

p.s. только у клиента может быть некорректно встывлена дата на компьютере, вот вам еще одна причина не делать проверку токена на клиенте

[Sport-code]

Alex,
Да, я уже разобрался, спасибо, на клиенте сделал вроде работает.
Хочу попробовать теперь на сервер запрос делать через BeforeEach

Answer 1

[Alex]

1. Вместе с токеном должено возвращаться время жизни токена.
   
2. Если такого нет, то в момент получения токена стоит сохранять время его создания и срок жизни.
   
3. Если срок жизни вам не известен, и сервер не предоставляет никакого инструмента для проверки токена, тогда вам стоит написать обёртку вогруг сетевого интерфейса: после обращения к АПИ, если сервер возвращает ошибку токен — получить новый и повторить запрос.
   

Comments

[Sport-code]

Да, вот возращает


Я просто не знаю как правильно проверить истекло время или нет, думаю через router.beforeEach или watch
и в них сделать обращение к серверу?
Т.к. выше писали что на клиенте не проверять лучше

Answer 2

[WebDev]

У вас есть время жизни токена, его и проверяйте в router.beforeEach. Больше ничего не надо.
Alex Александр Дроздов О чем вы говорите?
Если на клиенте злоумышленник изменит поле с временем жизни токена, токен от этого не станет "жить" дольше и на сервере все равно не пройдет и запрос отклонится.
Пинговать сервер в добавок к тому, что у вас на руках время жизни токена - это дикость какая-то.

Comments

[alex]

проверяйте в router.beforeEach

как?

spoiler

а если например злоумышленник изменит на клиенте например тот же exp в 10 раз, то получается что токен невалидный становится. но мы об этом не знаем, т.к. мы не пингуем сервер и не делаем вообще каких-то запросов(автор выше написал) и не верифицируем токен на клиенте. а если верифицировать на клиенте, то нам нужен секрет(на клиенте хранить секрет, wat?), ну или публичный ключ, но тогда у нас должна болеть голова о том чтобы на клиенте всегда был верный публичный ключ. + например сегодня у нас поле exp, а завтра бекендеру моча в голову ударила и он генерит токены с полем expiration_time - опять нужно следить. не легче пинговать сервер периодически? мб мои примеры надуманные, поправьте меня если я в чем то не прав, просто возможно я не очень прошарен в этой теме, а автору посоветовал вариант основанный на своем опыте.

[WebDev]

Alex, Не надо вообще думать о валидации на клиенте. Валидация на клиенте нужны лишь для того, чтоб пользователю что-нибудь показывать. Например мы подсвечиваем поле, если он недопустимые символы вводит или оставляет поле пустым. Все. Дальше валидация идет на сервере и там мы уже все проверяем.
Злоумышленник может делать на клиенте все что угодно и обойти любые проверки, потому что клиент находится у него. Но нам на это плевать, мы полагаемся на серверную валидацию и ни о чем не думаем.

[alex]

WebDev, не понял если честно при чем тут валидация данных, когда речь о токенах идет

[WebDev]

Alex, Валидация токена.

Answer 3

[Roman K]

Время жизни на клиенте самого токена проверять не надо:
1. JWT может быть httpOnly, иначе это прямой удар по безопасности в виде возможности сXSSить этот токен скриптами
2. У пользователя на ПК время может отличаться от серверного. Допустим, время жизни JWT — 5 минут, а у пользователя часы спешат на 6 минут. Этой разницы недостаточно, чтобы SSL не установилось, зато достаточно, чтобы твой скрипт навсегда зациклился в попытке получить "свежий" токен, думая, что он несвежий

Поэтому делаешь так:
После успешного получения JWT ставишь в localStorage текущее время пользователя (пренебрегая разницей между действительным временем истечения и временем исполнения твоей функции — оно скорее всего не будет превышать пинг пользователя + 100мс). Каждый запрос прерываешь с помощью какого-нибудь https://github.com/axios/axios#interceptors В этом "прерывателе" смотришь в localStorage и если прошло 50-80% (тут оставляем запас, потому что мы выше пренебрегли разницей + сам запрос может длится некоторое время [например, это могут быть сетевые задержки, или запрос будет лежать в очереди, пока воркеры заняты или какие-то запросы бэкенда в БД будут происходить до валидации JWT] + часы пользователя могут идти быстрее серверных и дать лишние пару микросекунд) времени жизни JWT — отправляешь сперва запрос на рефреш этого токена, а потом уже отправляешь сам запрос.

Comments

[Sport-code]

Спасибо )))
А по проще никак нельзя?
Сложновато без примера. %)