Как реализовывать JWT Symfony Logout?

Question

[user9823]

Всем привет
Задача следующая. Реализовал небольшое апи для авторизации и логина на симфони следуя этой инструкции
https://smoqadam.me/posts/how-to-authenticate-user...
теперь стоит задача разлогинивать пользователя
на фронте (вроде бы через Nuxt ) реализованы базовые методы delete которые просто выпиливают JWT из local storage
но на сервер запрос не попадает
собственно, мне каким то образом необходимо сохранять сессию в базе или ещё где-то и при разлогинивании пользователя выпиливать её оттуда, ну или например необходимо будет реализовать кнопку "выйти со всех устройств" или быстро разлогинить всех пользователей. Можно разлогинить их просто поменяв при этом secretkey для JWT но это не хорошо так делать.
У кого какие мысли? каким образом можно разлогинить пользователя через JWT ведь в нём в самом есть время экспирации, так что подмена и заход с нового устройства впринципе возможны

Answer 1

[apapacy]

Статья на которую Вы ссылаетесь содержит две распрстианенные ошибки в использовании JWT.
1. JWT используется для того чтобы не нужно было ходить в базу данных за данными пользователеля. Данные пользователя хранятся в JWT. Это немного увеличивает нагрузку на сеть, но сразу снижает в два раза количество запросов в базу данных. А это критично для нагруженных сервисов. Кроме того позволяет вынести авторизацию в отдельный миуросервис.
2. Вы наверное спросите а как же быть, если данные изменятся. Для этого сокращают время действия токена до минимального значения. Чтобы не проходить повторно процедуру авторизации, для возобновления действия этого токена выдается долгосрочный токен, предъявив котрый можно обновить краткосрочный токен и тем самым получить обновленные данные.

Возникает вопрос а что делать если пользователь был забанен или как в вашем случае разлогинился. Или просто его критически важные данные поменялись. Для этого организуют реестр аннулирования токенов, в котором записи хранятся на время действия токена. Такой реестр будет иметь сравнительно небольшой размер так как время хранения краткосрочных токенов невысоко. Его лучше организовать на быстрой базе данных key/value.

Ну и наконец сложный вопрос как аннулировать для Вашего случая долгосрочный токен. Если у токена нет срока действия то информацию о его аннулировании придется хранить вечно. Правда и запросов на его статус будет на порядок меньше чем запросов на статус краткосрочного токена.

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

Про разлогине нужно еще иметь в виду что он всегда будет немного сбойной операцией. Так как во время разлогина может отсутствовать интернет и вызов api закончится со сбоем.

Answer 2

[user9823]

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