а как бороться с "дебилами" которые не любят хранить полученные ранее токены и каждый раз просят выдать новый

Он в двух случаях нужен

Когда у тебя апи и когда ты хочешь сделать аутентификацию со своего сервиса в другом

ясненько

Поставить время жизни в 5 минут?

Но это подразумевает под собой, что отошёл на 5 минут от компа, тебя разлогинело

На самом деле такое время жизни токена оправдано например в банковском приложение, которое в публичном терминале например

Но я с такими не работал

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

я так понимаю, что концепция jwt токена в том что мы его не храним, он сам по себе, в себе содержит нужную информацию и подписан подписью, которая и проверяется при декодирование токена, помимо времени истечения

или же все таки jwt также требует хранения в базе, например чтоб можно было его быстро отозвать

меня вот как раз смущает хранимый в базе токен, и есть желание на login/password возвращать тот же токен, пока он не протухнет, т.е. новый генерировать только в случае устаревания текущего в хранилище.

блин ...

Jwt это oauth0

Паспорт это oauth2

Хотя так или иначе что первое что второе подразумевает рефреш

Просто никто его не реализует

Ну как никто

Маленькие проекты которые не шарят

А такой вопрос - почему может в created_at записываться null ?

У нас на азуре рефрешится

вроде одинаковые модели, одинаковые настройки таблицы а в одной created_at не создается

Через фасад, в таблице запись создаёшь без модели

Но на стороне Азура по идее он проверяется