у вас сервис, который выпускает токены на чём сделан?

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

ну хз как это работает под капотом в krakend, мы это не использовали, но возможность декларируется)

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

смотрите

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

ну собственно да, если объемы запросов очень большие - тогда jwt имеет преимущества, т.к. резко снижает количество запросов, если же запросов не так много - тогда можно остаться с сессиями и в ус не дуть. Ну и если у вас всякие микросервисы, то надо либо уходить на jwt, либо тащить сессии в отдельные хранилища и придумывать как с ними работать

Вариант с проверкой при рефреше, который я выше описал - вроде вообще дефолтный и не противоречит. Сервис, который дает токены и рефрешит, при рефреше таки сверится с тем, что токен не инвалидирован.


Вариант Антдрея мне даже нравится. Можно вообще сразу два кейса решить:

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

в итоге при каждом запросе не ходим куда-то, как при сессиям. Производительность сохранена. Разлогины есть

если мы не ходим куда-то при каждом запросе - у нас нет мгновенного разлогина

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

мы просто не далеко ходим)

пусть шлюз ообновляет свой кеш раз в пару секунд. ВВремязависит от потребностей

за сессией тоже не обязательно ходить далеко

Да понятно

тут же как с прометеем: вы снимаете нагрузку в виде действия на каждый запрос и превращаете ее в действие раз в какой-то период времени.

UPD: а мгновенность прям самая настоящая и не нужна. Вам надо решить 99% проблема - чтоб токен не был валиден еще 15 минут, а за несколько секунд перестал принимтаься шлюзом. Т.е. Закон Парето

т.е. сразу получаете масштабирование изи

не понмиаю, как вы не понимаете :D

какая разница микросервисы или нет?!

ну кто то передаёт jwt токен по всей цепочке вызовов других микросервисов при обработке входящего запроса

зачем?!