Как правильно обновлять jwt?

Question

[why7]

Хочу разобраться как правильно реализовать обновление jwt для web - приложения.

Путем гугления нашел ответ stackoverflow.com/questions/26739167/jwt-json-web-...
Но как я понял там предлагают хранить в самом токене время, когда текущий токен нужно заблокировать и выдать новый.
Т.е. получается, что если токен украдут, то его можно использовать до бесконечности т.к. при наличии токена и истечении времени обновления, выдается новый валидный токен. Или забиваем на проблему кражи токена, надеясь на HTTPS?

Еще натыкался на схему с jwt и refresh токеном, типа новый jwt можно получить только если предъявить refresh токен. В такой схеме я видел следующую ситуацию:
1. Клиент делает запрос на сервер передавая уже просроченный jwt
2. Сервер отдает 401/403
3. Чтобы конечному пользователю не проходить аутентификацию снова, клиент ловит эту 401/403 ошибку и делает запрос на получение нового jwt предъявив refresh
4. Сервер выдает новый jwt (и возможно плюс новый refresh токен еще) и клиент повторяет запрос №1 но уже с валидным jwt и все почти счастливы.
Для конечного пользователя такая схема, скорее всего, будет выглядеть долгой загрузкой страницы.

В итоге, как же правильно обновлять jwt, чтобы это было безопасно и конечный пользователь был доволен?

Comments

[DTX]

Случайно решения не нашлось?

Answer 1

[DTX]

cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt...

TL;DR Сессии - наше всё

Answer 2

[Barmunk]

У токена должен быть короткий срок жизни, к примеру 60 минут. После того, как токен протухнет у вас есть 2 выбора:

1. Авторизоваться заново по логину паролю и получить новый токен на 60 минут. В этом случае срок жизни токена минимален и можно не заботиться о его краже. Авторизация проходит раз в час, что усложняет кражу пароля, но если его и украдут, то срок жизни токена мизерный.

2. Воспользоваться методом рефреша просроченного токена. При этом такую возможность нужно ограничить временем, к примеру максимум 14 дней после истечения существующего токена.

Возможность выхода из сессии с занесением в черный список текущего еще действующего токена. Он может храниться прямо в кэше и удаляться, когда его время жизни закончится.

Я для себя выбрал первый вариант с возможностью выхода из сессии для особых параноиков. Если текущий токен будет украден, то клиент меняет пароль, а его выданный токен заносится в черный список. Через 60 минут можно считать, что клиента мы защитили. А рефреш я не стал делать, потому что в случае кражи могу не уследить за выданными или обновленными токенами.

Comments

[why7]

Если я правильно понял, по первому варианту получается, что пользователю через каждые 60 минут нужно будет перелогиниваться?

[Barmunk]

why7: да, само собой не руками)

[DTX]

Спасибо, поржал)

[DTX]

Barmunk, не руками, а как? Хранить логин-пароль и отправлять их на авторизацию?

[DTX]

Лол, вопросу больше года. Я хз, как я тут оказался xd

[Barmunk]

DTX, расскажи над чем поржал, может тоже посмеюсь

[DTX]

Barmunk, ну я же задал открытый вопрос. Может, там всё и правда очень серьёзно

[DTX]

Barmunk, поржал над тем, что в этой схемы от рекомендуемой схемы использования JWT не осталось почти ничего. И что, по всей видимости, вы отправляете креденшелы пользователя раз в час на сервер.

[DTX]

Так можно, пожалуйста, услышать ответ на вопрос о том, как происходит повторная авторизация?
Я сам просто jwt не осилил и решил от него отказаться.

[Barmunk]

DTX, при запуске любого метода сервер сообщает, просрочен токен или нет. Если токен оказался просрочен, у вас 2 выбора:

1. продлить существующий с помощью рефреш токена
2. выпустить новый, авторизовавшись заново

под выпуском нового токена, подразумевается специальный метод для авторизации, который ждет логин пароль и на выходе выдает новый токен.

считайте jwt упрощенным 0auth2 и все станет понятно.

[DTX]

Barmunk, в первом комменте написали, что повторная авторизация может происходить не руками. А как тогда?

[Barmunk]

DTX,

POST
http://site.ru/api/auth/login
-login:user
-password:pass

response 200
-token 123qwerty123

POST
http://site.ru/api/some-data
bearer token 123qwerty123

[DTX]

Barmunk, хранить где-то логин-пароль пользователя непростительно.
С тем же успехом можно всё делать вот так:

POST
http://site.ru/api/some-data
-login:user
-password:pass

Ну и токен лучше в хедерах передавать

[Barmunk]

DTX, вы теряете первоначальный смысл api. Он же не в вакууме. Пользователь регистриуется где-то, у него есть интерфейс, какие-то его локальные права. На основе этого всего делается как раз апи, тот же вход, только получает он не доступ в лк, а отвязанный ключ на определенное время, по которому уже ходит по доступным именно ему методам. Через какое-то время его сессия истекает (токен) и он решает что с этим всем делать, программно авторизовать заново или продлить сессию.

Где он хранит свой пароль, как он его шифрует, каким образом он передает токен уже не ваше дело. Это и называется (stateless token authentication)

bearer token передается в header

[Дмитрий Свиридов]

DTX, зашел сюда еще через год: логин и пароль нигде не хранятся, вы неправильно поняли. Продление access-токена делается не через них, а с помощью refresh-токена. Советуете юзать сессии? Ну и как, удобно их в SPA юзать?

[DTX]

Дмитрий Свиридов, да сессии это те же урезанные jwt.
Если самому все кодить проект не серьезный, то да.

Но я сейчас ушел на jwt от firebase. Там сразу все есть, самому делать ничего не нужно. Меня устраивает)