Как правильно проверять и обновлять refresh jwt?

Question

[Boris007]

Нашел в интернете такой пример таблицы для refresh jwt

CREATE TABLE IF NOT EXISTS refresh_tokens (
    id serial PRIMARY KEY,
    user_id INT NOT NULL REFERENCES users (id),
    token VARCHAR (255) NOT NULL UNIQUE,
    iat int NOT NULL,
    exp int NOT NULL
);

Подскажите, как правильно работать с записями jwt в таблице?

1)Пользователь при логировании ищет свою старую запись jwt по каким-то полям или всегда создается новая?
2)При завершении работы access token мы refresh token создаем новый или перезаписываем в текущий, просто меняя значение exp?
И при проверке на наличие актуальности текущего токена, мы его ищем по сходству полей user_id AND exp?
3)При выходе пользователя из аккаунта, мы запись удаляем или как-то аннулируем и при повторной его логировании в нее запишем новый рефреш токен?
4)Как происходит поддержка двух рефреш токенов для разных устройств или браузеров?

Comments

[VolgaVolga]

Например.

Answer 1

[Петр]

1. В Refresh токене уже есть нужная информация. И в ответ выдается новый Access Token
2. В подписанном Access Token не получится подменить exp. Так что новый
3. Откуда выходим? В Web client можно просто забыть Access Token. Но если у кого-то останется refresh token, то можно получить новый Access Token.
Если хочется чтобы его нельзя было использовать после выхода, то в Access Token и Refresh token, добавляется RefId. И если RefID в заблокирован, то новый получить Access Token из Refresh будет нельзя.
4. Каждый конект имеет свой Refresh token, так что не получите и там и там одинаковый

Comments

[Boris007]

Спасибо, подскажи еще пожалуйста

Получается при обновлении токенов, делать запрос по сходству user_idAND refresh_token?

А как быть при выходе из аккаунта, нужно стирать запись в БД или просто удалять в колонке значение refresh_tokenи при следующем логировании искать user_idи вписывать новое значение refresh_token?

И если у нас два и более устройств, как этот момент учесть?

[Петр]

Boris007, если есть несколько устройств и выход должен быть сразу со всех, то следует вводить RefId.
Для примера сущность Refs (id, userId, validFrom, validTo). И прописывать RefId как в Access Token, так и Refresh Token.
При выходе вы для записи с RefId прописываете validTo = Now. При обновлении Access Token через Refresh сходство refresh_token проверять не нужно, а просто распарсить его и проверить RefId, если он еще активен, генерите новый Access Token.

[Boris007]

Петр, подскажи пожалуйста, при генерации нового access_tokenнужно же и новый refresh_token создавать, верно, а то мне показалось, что с твоих слов он не пересоздается?

А сам токен в нем хранить не надо?
Я думал в таблице идет поиск по user_id AND token
Refs (id, userId, validFrom, validTo)

Так, а при выходе, как мы потом сюда же запишем новый токен?
Или просто ищется любая запись с user_id у которой validTo=now и записывается в нее?

Но как быть, если злоумышленник зашел по украденному токену?
У нас пользователь разлогинется через 5 мин, но если он зайдет снова, у него создастся тогда новая запись refresh_token, а та, которую украли, так же останется рабочей и будет обновляться

[Петр]

Boris007, Модель то ответа стандартная, удобно и при логине и при рефреше

{
  "token": "string",
  "validTo": "2023-11-10T20:06:29.320Z",
  "refreshToken": "string"
}

А значит и refresh пересоздайте.

У вас информация прописывается в токен, вы его можете распарсить и получить нужное, в БД писать не нужно. Парсится как Access, так и Refresh. Но последний еще и шифруется

[Петр]

Boris007,

Но как быть, если злоумышленник зашел по украденному токену?
У нас пользователь разлогинется через 5 мин, но если он зайдет снова, у него создастся тогда новая запись refresh_token, а та, которую украли, так же останется рабочей и будет обновляться

От этого никто не застрахован. Для уменьшения рисков, Access Token имеет короткое время жизни.
Refresh больше, но он реже используется.
Делайте разлогин по RefId и тогда все токены станут не вылидными, что были получены до разлогирования