Отзыв токена

Понимаю, что всё давно придумано и проверено, но хочется меньше оверхеда.
Вопрос чисто по архитектуре решения, не по реализации. т.к, возможно, я не вижу какие-то принципиально иные подходы.

авторизация тут не рассматривается, только аутентификация

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

[1]
Популярный сейчас вариант реализации - бэкэнд, потребляющий JWT, на этапе валидации конкретного токена, никак с сервисом его выдавшим не взаимодействует (ну, т.е. периодически актуализирует ключ для проверки подписи, но это фоново):
1. Сервис аутентификации по логину/паролю выдаёт access-token и refresh-token. Первый - действует несколько минут, второй - долго.
2. Сервис (бэкэнд), который потребляет access-token просто проверяет подпись и срок действия.
3. Если access-token просрочился, то клиентская часть получает от бэка 401, идёт на сервер аутентификации и без логина/пароля по refresh-token получает новый access-token. И на этом этапе сервер аутентификации может выдать отказ, если аккаунт был забанен, или если пользователь изменил пароль.

Плюсы:
- во втором пункте минимальные затраты ресурсов и минимальное время выполнения.
- есть готовая реализация в виде IdentityServer.
Минусы:
- время отзыва токена после блокировки аккаунта или смены пароля определяется временем жизни access-token.
- фронт/клиент вынужден регулярно получать 401 от бэкэнда и ходить за новым access-token, а это задержки для пользователя и регулярные дополнительные запросы. Даже если фронт сам будет проверять срок жизни токена, это всё равно регулярные вызовы на обновление токена и дополнительная логика фронта.

[2]
Очевидный вариант избавления от указанных выше минусов:
1. При каждой валидации токена на бэкэнде, делать дополнительный запрос к сервису аутетнификации для проверки, не отозван ли токен.

Плюсы:
- фронт/клиент не получает дополнительной нагрузки/задержек на регулярных перезапросах токена и 401-ответах от бэкэнда.
- отзыв токена происходит моментально.
Минусы:
- страшный минус - при каждой проверке токена, при каждом, даже самом маленьком запросе, происходит полноценный HTTP-вызов другого сервиса, а это дополнительная задержка в обработке каждого запроса к бэку.
- даже если поверх IS4 реализовывать, всё равно немного велосипед получается.

0

Вообще, складывается впечатление, что JWT в чистом виде в реальных проектах смысла не имеет, т.е. как самодостаточная единица аутетнификации. Т.е. всё равно, в том или ином виде, реализуются сессии для управления ранее выданными токенами, а при каждой проверке токена на бэкэнде всё равно выполняется дополнительное обращение к хранилищу (или другому сервису) для проверки актуальности полученного токена.

0

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

1

Можно хранить блеклист токенов в распределенном кеше, например Redis.
Обращение к кешу по идеи должно быть быстрее чем http запросы к сервису аутентификации.

1