Как правильно реализовать авторизацию через JWT?

Здравствуйте, понимаю что уже есть куча статей по этому поводу, но всё таки решил задать ещё вопрос, чтобы более прояснить.
Вопрос заключается в способе отзыва и осуществления контроля над токеном, без хранения заблокированы токенов в БД, и возможностью оперативно его блокировать?
  • Вопрос задан
  • 2348 просмотров
Пригласить эксперта
Ответы на вопрос 3
@jacob1237
Используя пару access_token и refresh_token, попробуйте уменьшить время жизни access_token, например до 10 или 20 минут.
Хранить access_token'ы в базе данных смысла нет, так как главная фишка JWT не столько в stateless сессии, сколько в децентрализации (вернее, одно проистекает из другого).

Таким образом серверы, принимающие access_token, могут проверить его правильность без необходимости использовать какие-то внешние сервисы.

И да, основной побочный эффект в этом случае как раз заключается в том, что даже после блокировки refresh_token, access_token будет действовать еще какое-то время.

Это всегда некий компромисс между удобством и безопасностью.
Ответ написан
Комментировать
Расскажу как делал я.

Создаём пару refresh_token и access_token и сохраняем в БД.
{
  refresh_token: XXX,
  access_token: YYY,
  user_id: ZZZ,
  client_id: A,
}


Отправляем оба клиенту.
Для запросов используется access_token, он содержит нужную инфу о юзере и в БД лезть не заставляет.
Чтобы получить новую пару, используем refresh_token. Старую пару при этом можно удалить, чтобы не раздувать БД.

Остаётся проблема с тем, как заблокировать access_token.
Я использую Redis для хранения списка заблокированных токенов, при этом хранятся они не больше времени жизни токена.

Итого:
Авторизациям > запрос к БД > получили токены
Запрос с токеном > проверка на отсутствие в Redis > расшифровка токена
.... через 60 минут (или другое время жизни токена)
Запрос на обновление токена > запрос к БД > новые токены > запись в Redis

Такая схема позволяет авторизоваться на нескольких устройствах сразу, управлять своими авторизациями (выйти со всех устройств, выйти с устройств А и В).
Ответ написан
zoonman
@zoonman
⋆⋆⋆⋆⋆
Я использую достаточно своеобразный подход к выдаче JWT.
У каждого пользователя есть специальное поле, назовем его passId. Оно меняется при смене пароля. Просто генерируется из /dev/random. От этого поля считается хэш и добавляется внутрь JWT. При проверке токена сверяется passId. При необходимости можно усложнить схему и выдавать passId на каждое устройство индивидуально.
Также связку user:passId легко хранить в любом NoSQL-хранилище и упреждающе обновлять там при смене пароля/компроментации аккаунта.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы