Как разлогинить пользователя? в Asp.Net Core

Я с помощю claims генерю jwt-токен для пользователя который правильно авторизовался, на калиенте каждый раз в header запросе передаю этот токен. В один момент администратор заблокировал этого пользователя за плохое поведения, как теперь разлогинить этого пользователя ?

0

.. как я понимаю, все не так просто, но варианты гуглятся, например:

Canceling JWT tokens in .NET Core

0

anuartemirbolat, такие вещи делаются введением нового понятия "сессия".

Заводится новая сущность и новая таблица "Сессия". В сессии есть ссылка на таблицу пользователей. При авторизации, пользователю выдаётся новая сессия ID которой пихается в payload токена. Токен считается валидным, если валидна сессия в базе. У пользователя может быть N (но не более!) одновременных сессий.

Отзыв сессии в базе - отзыв авторизации пользователя со всех устройств и браузеров.

0

Usaga, при каждом запросе, придется стучаться в бд?

0

anuartemirbolat, зачем? Кешировать. При принудительном "разлогине" сессии пользователя из кеша выкидываются.

0

Несколько вариантов на выбор
1. Самый простой, деавторизовать всех, сменив ключ или любой параметр валидации токена, ишуера, аудиенцию итд..
Плюсы: Быстро, легко
Минусы: Костыль
2. Уменьшаем время жизни токена, добавляем Флаг в бд, который проверяет возможность авторизации юзера, к примеру "IsBanned"
Плюсы: Получаем относительно слабый контроль авторизации (зависящий от времмени жизни токена)
Минусы: Время жизни, меньше, авторизация чаще, после "бана" юзера может остаться определенный валидный период.
3. Уменьшаем время жизни токена, вводим понятие рефреш токена, который сохраняем в бд - при необходимости этот рефреш-токен отзывается, лешая возможности обновить токен авторизации.
Плюсы: Получаем относительно слабый контроль авторизации (зависящий от времмени жизни токена), механизм для обновления токена авторизации
Минусы: после "бана" юзера может остаться определенный валидный период.
4. Проверка доступа пользователя в каждом запросе, любой флаг, или сессия как писали выше
Плюсы: Максимальный контроль авторизации
Минусы: Лишний запрос к бд при каждом обращении в авторизованую область, если не использовать кеширование
5. Заводим отдельный список отозванных токеннов\забаненых юзеров, при необходимости список можно кешировать в памяти
Плюсы: Максимальный контроль авторизации
Минусы: Лишний запрос бд при каждом обращении в авторизованую область, если не использовать кеширование. (данных при этом меньше, чем в предыдущем способе)

0

Сообщение от lvlkoo 5. Заводим отдельный список отозванных токеннов\забаненых юзеров, при необходимости список можно кешировать в памяти

Отдельно взятое это решение очень такое себе. Потому, что неизвестно как долго нужно держать "ориентировку" в памяти. А вот вкупе с №3 вполне себе проканает.

0

6. Создаем отдельные записи точек входа, сохраняем ip-адрес, имя компьютера, тип операционной системы, полученную информацию сохранить и добить в токен. Валидацию проводить со сверкой точки входа. Нет в списке - гоу на логин. Надо разлогинить одно устройство - удалить из списка. Надо разлогинить на всех устройствах - очистить список.

Плюс: круто, че. Прям как у Гугла.
Минус: надо бы сервак помощнее, дискового пространства побольше, и тогда не будет минусов, а будет примерно как-то так

Миниатюры

 

0

Сообщение от lvlkoo 4. Проверка доступа пользователя в каждом запросе, любой флаг, или сессия как писали выше Плюсы: Максимальный контроль авторизации Минусы: Лишний запрос к бд при каждом обращении в авторизованую область, если не использовать кеширование

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

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

P.S. Вот я лично не считаю минусом лишние запросы к базе. От них все-равно никуда не денешься, а частенько сложные запросы выполняются быстрее, если их раздробить на мелкие и вместо одного большого с кучей лефтджоинов отправить 3-4 мелких, а потом все смержить в памяти.

0

Сообщение от yurickas 6. Создаем отдельные записи точек входа, сохраняем ip-адрес, имя компьютера, тип операционной системы, полученную информацию сохранить и добить в токен.

Нафига?

0

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

0

yurickas, кто вам сказал, что пацаны с картины всё это в куки засунули?)

0

Сообщение от Usaga кто вам сказал, что пацаны с картины всё это в куки засунули?)

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

0

Сообщение от yurickas А в токен можно что угодно запихать

Ага. К примеру ID какой-то записи, в которой можно хоть Войну и Мир затолкать. Не находите, что это проще и лучше, чем пихать всякое дерьмо в сам токен?

0

Ага. Ну, тут еще есть масса вариантов, но по факту главное общее описание, а не частная реализация. Человек же совет спрашивал.

0