Рефреш у вас каждые 10 секунд?

За два месяца можно многое сделать)

ты понимаешь в чём фишка рефреш токена или нет?

Я понимаю, чем сессии не нравится?

я же написал выше, в чем его фишка

как по твоему чел зайдёт по рефреш токену, если в базе данных токена лежать не будет? Он юзлес, а access можно сделать секунд 30

Это тут причем

зачем тогда жвт нужен, если токены в базе лежат?

.

В базе jwt не хранят, в базе рефреши хранят

У людей шиза, это же классика, сколько говна уже все поели по поводу хранения рефреша в бд, отсутствия его и отзыва токенов

мне вам расписывать статью или просто в интернете почитаете зачем нужен?

вместо просто сессии 🤷

Так фишка jwt в том чтоб не обращаться к бд

в интернете любая статья == “уникальная технология не имеющая аналогов в других странах”

Так его и не хранят в БД

Нет, потому что сессия (сервер сайд сессия) подразумевает наличие только сессии

с которой делай что хочешь, раз уж обращаемся к бд периодически (чем чаще, тем безопаснее)

JWT позволяет делать делать stateless (без хранилищ, бд и та) аутентификацию и авторизацию в распределенном приложении. В паре с ним используют refresh, чтобы решить проблемы безопасности. Рефреш - да, лежит в БД. Но рефреш используется одним сервисом - сервисом авторизации, а не всем распределенным приложением

А если распределение приложение требует отзыва токенов?

Какого из двух?

Обоих

Тогда такой тип авторизации не подходит приложению

Вот)

вот jwt для того придумывали, чтобы распределенные приложения были распределенными, без единого места для авторизации. я понимаю, как оно работает и вижу, что сделали ни то ни сё. вроде стейтлесс, а вроде централизованно надо

Вот что? Нашелся случай, когда такой тип авторизации не подходит?

Не понимаешь, если аппелируешь к неободимости наличия БД для рефреша. Авторизация работает без БД во всем распределенной приложении. Рефреш с БД используется в одном сервисе, а не всем распределенном приложении. Одному сервису иметь для своей работы свою бд - не тоже самое, что для всех

у меня 5 сайтов есть с единой авторизацией. мне еще один сервак поднимать, чтобы у них общая база для рефреш токенов была?

Я где-то писал, что тебе или кому-то ещё НУЖЕН jwt? Я объяснил только, почему вашу предпосылки - ложные

Jwt он всем нужен, его всем не хватает 😳

в этом и вопрос: в каких кейсах jwt подойдет, вот, прям, чтобы идеальненько?

тут я не знаю уже, какой вариант. и то и другое интересно было бы узнать

Необходим - нигде. Как минимум, всегда можно заменить JWT на любой другой вариант подписанного токена, что придумывали ещё во времена сессий с client-side сессиями. А где используется, можно с маленькими потерями перейти на авторизацию в отдельном сервисе или менять сетевую архитектуру приложения. Подойдёт - в распределенном, микросервисном приложении без центрального gateway-я, где не хочется каждому сервису завязываться на сервисе авторизации или быть привязанным к общей бд для более независимой разработки by design слабосвязанных сервисов

короче, теоретически небольшая экономия на запросах к авторизации в ущерб безопасности пропорционально частоте рефреша токена

Я не писал про экономию

это я для себя вывод сделал промежуточный

Только не надо ему тогда приписывать мое сообщение в предпосылки)

не приписывал) думал все-таки найти хоть один плюс для себя 🙂

self-signed токен позволяет новому разработчику/команде разрабатывать новый сервис ничего не зная про сервис авторизации и его местоположении, кроме формата токена

Для пета разрабатываемого одним человеком на одной машине - никаких

а рефрешить его как? повторюсь - на работе это решено готовой инфраструктурой

рефрешить кому? клиенту?

да, т.к. он в какой-то момент может стать ядовитым

клиент просит новый у сервиса авторизации

в этом и вопрос: если уж стучимся иногда к авторизации - значит сервисы связаны единым центром, в случае отказа которого новый токен не получить будет, как и в случае с сессиями