Ну по дефолту верификация включена. Это ж надо специально  верификацию выключать

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

ты слишком просто объяснил, там её вообще было, сверялся только username)

да дело даже не в либах, а в басфакторе конкретного погромиста который это писал

и даже не всегда спасает верификация по секрету)

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

Тут не ручаюсь, но по-моему так

еще такое бывает

🔗
По мотивам предыдущего поста про base64. Если бегло пробежаться по гитхабу, то можно найти дохрена примеров отзыва JWT токена через добавление его как есть в черный список. In-memory или в redis какой-нибудь. Прямо в base64 форме.
Проблема в том, что два токена:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.CDfhHu9_n2jSQGHcUwmSgZLL1OKEGjK4hw6D3Q40MA0
и
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.CDfhHu9_n2jSQGHcUwmSgZLL1OKEGjK4hw6D3Q40MA1
оба валидны (можете сами проверить на https://jwt.io/ секретный ключ - secret6). И если добавить в черный список только один, то можно поправить один символ и ходить на апи дальше.
Если вы думаете, что люди так делать не будут, то ошибаетесь. Я спросил в чате про го народ как они блочат токены и первый ответ был именно такой. Или вот библиотека на гитхабе на 13 тысяч звездочек https://github.com/feathersjs/feathers  и в документации у них написано делать именно так https://docs.feathersjs.com/cookbook/authentication/revoke-jwt.html

По сути это у кучи народу дыра в безопасности. На практике она минорная и хрен заэксплуатируешь, баунти за неё не получишь, а ходить репортить просто так лично мне лень.
Вот такое вот IT-говно.

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

Вообще интересно, емнип jwt токен это неотзываемая штука и валидируется только по подписи и дате/времени жизни, а отзываться должны рефреши

отсекать по дате это только для фронта, на беке не достаточно)

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

смысл рефреша в том что-бы один токен долго не существовал )

да рефреш можно убрать, но надо сделать дату протухания скажем пару месяцев ну или как там решите)

меня один раз на галере подбили сделать вообще дичь, фронтендерша не хотела сделать логику с рефрешем проверять дату протухания, мне сказали время жизни токена час, я сделал офигенное г, я проверял этот токен по науке и смотрел на дату протухания, если ко мне идёт запрос и время жизни меньше 5 минут, я выпускал новый токен) не делайте так) лучше рефреш

Рассказываю. Смысл только в производительности. У тебя есть коротко живущий токен, которыйне проверяется по списку валидных, блэклисту, блокировки Пользователя. А вот когда ты делаешь рефреш, то в этот момент делаются все возможные проверуи5

https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc вообще вот кому надо

Не увидел г. Это нормально выдавать новый токен, когда видишь, что старый устаревает. Но это работает, если токен в куках лежинт. Есть ещё нюансы, с тем чтобы не выпустить 10 новых токенов, когда фронт послал 10 параллельных запросов.

ну да я его закинул в куки под секурити и еще один параметр, забыл как называется