Как истечь токен JWT вручную?

Question

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

Существует система инвентаризации, построенная как REST API , и существует два типа пользователей.

1. users
2. admins

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

email, user_id, user_level

Этот токен декодируется на каждом частном маршруте и проверяет, аутентифицирован ли пользователь, а также проверяет уровень пользователя, чтобы убедиться, что пользователь авторизован для доступа к этому конкретному ресурсу.

Давайте рассмотрим специальный сценарий, когда администратор ( Admin A ) входит в систему и начинает выполнять некоторые действия администратора в системе. Внезапно другой администратор ( SuperAdmin ) хочет понизить Admin A до обычного пользователя по какой-то причине. Однако, хотя теперь Admin A является обычным пользователем, его токен все еще остается токеном администратора. Таким образом, он все еще может выполнять действия администратора, пока токен не истечет автоматически через один час.

Итак, в таком сценарии, как можно истечь этот токен вручную? Должна ли система использовать запрос БД для проверки уровня пользователя для каждого маршрута администратора? Или есть какой-то другой способ добиться этого?

Надеюсь, вы это ясно поняли.

Answer 1

Один жизнеспособный способ справиться с этим - поддерживать кэш, состоящий из JWT / состояния пользователей, чьи права были изменены с момента выпуска их первоначального JWT. Рабочий процесс обычно go выглядит примерно так:

• Ваша система выдает административный JWT определенному пользователю
• Некоторое время этот администратор использует свой JWT как обычно
• Тогда супер администратор решает понизить рейтинг администратора. Поскольку он не может отозвать свой JWT, вместо этого он записывает запись в кэш черного списка, записывая, что этот пользователь больше не является администратором.
• С этого момента сервер сначала проверит все входящие запросы в кеше черного списка. решить, какую информацию использовать. В случае примера администратора сервер обнаружил бы запись в кэше и затем предоставил бы этому пользователю обычные права без прав администратора.
• При условии, что у вашего JWT есть дата истечения срока действия, кэш в конечном итоге удалит устаревший JWT, сохраняя минимальный объем памяти.

Ключевым моментом в отношении кеша является то, что он работает быстро. Доступ к записи в кэше должен быть примерно в 100 раз быстрее, чем попадание в базу данных. Что касается устаревших устаревших записей в кеше, многие реализации кеша, такие как Redis, позволяют устанавливать срок действия записи при ее записи. В этом случае сервер просто установит срок действия с помощью утверждения exp внутри исходного JWT. При правильной настройке требования к кэш-памяти могут быть сведены к минимуму.