Какова стандартная практика хранения токенов JWT в Redis?

Question

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

Answer 1

Поскольку @ Гай Корланд уже охватил основную c идею JWT, я прокомментирую два подхода, о которых вы упомянули.

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

Этот подход не очень полезен, если все, что вы пытаетесь найти в Redis, это информация о пользователе. Это связано с тем, что пользовательская информация может быть напрямую сохранена как claims в разделе payload JWT, что позволяет избежать вызова поиска из Redis. Если claim содержит конфиденциальную информацию, всегда можно зашифровать токен JWT, чтобы гарантировать, что к нему не обращаются непреднамеренные получатели.

При этом недостатком является отсутствие необходимости обращаться к кешу вообще. что вы не можете аннулировать / обновить sh токены. В общем, рекомендуется, чтобы у вас не было долгоживущих токенов, так как это уязвимость безопасности.

если я закодирую пользовательские данные в самом JWT и использую Redis только для хранения действительных токенов

Это лучше, чем предыдущий параметр, и работает, если информация пользователя закодирован как часть токена JWT. Также вы можете сохранить «контекст» токена как значение в Redis (ключом является сам JWT). «Контекст» здесь означает, что в последний раз токен использовался (lastAccessTime), интервал истечения и т. Д. c. Используя этот «контекст», вы можете определить, является ли сеанс активным / неактивным и следует ли аннулировать токен и предоставить клиенту токен fre sh.

Answer 2

Вся идея JWT заключается в том, что при каждом вызове не требуется доступ к БД (или Redis), а данные доступа пользователя будут закодированы в токене.

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

Хорошим компромиссом, если вам нужен способ активной отмены токенов, является использование метода быстрой проверки, который, например, может основываться на Bloom Filter, и для этого вы можете использовать RedisBloom.