Токен внутри полезной нагрузки JWT - PullRequest
0 голосов
/ 14 июня 2019

Является ли хорошей идеей иметь случайно сгенерированный токен внутри полезной нагрузки JWT и проверять базу данных при каждом запросе?

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

Мне также нужен хорошийРешение немедленно отозвать токен, если мне нужно.Чёрный список токена изначально кажется хорошим решением, но для этого потребуются дополнительные запросы, и я не думаю, что оно того стоит.

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

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

Таким образом, решение будет таким:

Когда пользователь регистрируется,он назначается с randomToken и также сохраняется внутри полезной нагрузки.Если регистрация прошла успешно, сервер возвращает сгенерированный jwtToken.

var jwtToken = jwt.sign({token: randomToken}, PRIVATE_KEY, SIGN_OPTIONS);

Поэтому, когда пользователь делает новый запрос, он сначала проверяет, является ли токен JWT действительным.

var legit = jwt.verify(token, JWT_PUBLIC_KEY, SIGN_OPTIONS);

Еслиэто значит, что он выполняет проверку токена внутри полезной нагрузки с помощью токена пользователя в базе данных.

SELECT * FROM users WHERE token = legit.token

Если все верно, он затем выполняет обычный запрос.

1 Ответ

0 голосов
/ 14 июня 2019

«Это хорошая идея ...» - не очень хороший способ задать вопрос, но я постараюсь ответить на него ...

1. JWT безопасен

Причина использования закрытого ключа заключается в том, чтобы убедиться, что пользователь не меняет токен. Следовательно, абсолютно безопасно хранить объект, который часто используется в токене, и нет необходимости хранить токен где-либо. Подписанный объект будет выглядеть так:

{
  expirationDate: 1560530063664,
  ...user data
}

2. Черные списки и отзыв токенов

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

Хотя может быть неплохо иметь возможность занести в черный список токен, действительно ли это необходимо? Если пользователь обновляет свой пароль, действительно ли он должен выйти из системы? Если вы все еще думаете, что вам нужен магазин токенов, я думаю, что для этого есть несколько пакетов npm ...

...