А так жвт- сизифов труд

То есть мало просто переизобрести токены.
Нужно кричать "НЕ Я ПРИДУМАЛ, ДРУГИЕ ЮЗАЮТ"

Ведь подумать своей головой вообще никак

пока все остальные подтирались левой рукой

Таймураз - жду обещаного...

JWT нужны в первую очередь, чтобы подписывать запросы и ответы. А также иметь возможность валидировать этот ответ.

То, что их используют как замену сессиям, это выбор этих людей. И никто не гарантирует, что выбор правильный

!ро Серый, заебал

А по поводу JWT, просто напомню, чтобы не было перевирания:
- человек четко дал понять, что ему это нужно просто для учебного проекта, максимально просто - это реально самое простое в данной ситуации
- еще как вариант я выше предложил хранить данные роли вместо БД в памяти/редисе чтобы не долбать БД постоянно

И да, всякие-разные механизмы со временем устаревают, но это не значит, что их нельзя юзать

Но вообще правильнее было, наверное, узнать сначала: Илья, а при каждом запросе юзера с токеном, как этот токен проверяется - через запрос к БД или он живет в памяти?

Ну идея такая,access токен живет около 2 мин ,а refresh 3. По истечению времени access токена я обновляю access токен и refresh токен(который лежит в базе данных)Первый раз авторизацию пишу))

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

А как проверяется валидность этого access_tokena, когда с ним приходит запрос от юзера?

Вот бек выдал токен(ы) юзеру, и пришел с этим токеном запрос от него за инфой. Как проверяется, что пришедший токен честный, в БД проверяете или в памяти живут токены?

Ребят, по правам смею предложить решение под названием keyckoak

Ну в payload храниться поле тип со значением 'access')Я еще наверно не дошел до проверки токена)) Я просто прверяю ,что он access или нет) Access токен хранится в localstorage у пользователя и в headers его с каждым запросом отправляю (добавляю заголовок в интерсепторе перед отпрвакой).

Я его декодирую с помощью jwt.verify,проверяется его время и валидность )

В try catch оберни. Верифай выбрасывает ошибку, когда токен не валидный. Либо передавай коллбэк

Да,я так и делаю)

А, ну тогда ладно)

Суть решения в том, как вы обрабатываете запросы на беке, и от этого лучше отталкиваться, основных варианта два:
- вариант первый: в токене (см. JWT) есть все данные и срок жизни для того, чтобы определить отдать юзеру некий ресурс или нет, в таком случае вполне допустим вариант хранения ролей в составе JWT и подписывать его секретным ключом для защиты от подделки самого токена
- вариант второй: для проверки токена бек обращается к какому-то своему хранилищу, где проверяет наличие этого токена и данные юзера этого токена, в таком случае нет профита что-то придумывать, можно доп. данные по правам/ролям хранить/дергать в одном запросе к хранилищу для получения и ролей/прав

Вот собственно мидлвара))