Max Voronov: почему теряются? основной плюс jwt что он self-contained и что нам не надо запрашивать БД при каждом запросе. refresh token это как одна из технологий, это не стандарт, это всегда на твое усмотрение. Лично мне бадяга с refresh токенами не нравится, она во многих случаях бессмысленна, сильно усложняет клиентский и серверный код и добавляет ни к чему ненужную овер псведосекьюрность.
Вообще без блеклиста ты никак не обойдешься. Как ты будешь инвилидировать refresh token? Делать точно такой же запрос в БД.
Мое предложение в том, что в большинстве приложений будет достаточно стирать токен с клиента и все. И как доп. секьюрность блеклист в редисе для исключительных случаев (типа завершить все сеансы), который будет работать практически мгновенно.
Я немного не уверен, что вы до конца разобрались в JWT. Но в любом случае буду рад услышать ваши идеи и предложения.
Если овер секьюрность не требуется или если это только апи для мобилок, да еще запросы передаются через ssl, то не заморачиваться, а сделать долгоживущий токен (например полгода-год), который при sign out удаляется с клиента. Ну и еще добавить blacklist для фичи аля "завершить все сеансы" если клиент считает что токен скомпрометирован. Этого будет достаточно.
Это шутка такая что ли? Ужас. Во-первых мы не знаем к какому юзеру привязан токен, пока мы его не расшифровали. А значит хранить user_id:secret это бессмыслица. Встает вопрос что хранить? Сам токен? Иметь отдельную БД которая хранит всю секьюрную информацию? А если мы ее потеряем? Не знаю кто все, кто так работает, но это жесть
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Вообще без блеклиста ты никак не обойдешься. Как ты будешь инвилидировать refresh token? Делать точно такой же запрос в БД.
Мое предложение в том, что в большинстве приложений будет достаточно стирать токен с клиента и все. И как доп. секьюрность блеклист в редисе для исключительных случаев (типа завершить все сеансы), который будет работать практически мгновенно.