Какая верная стратегия обновления refresh_token'а для нескольких устройств?

Question

[unroot]

Разбираюсь с JWT, в частности с refresh token'ом. Не получается продумать стратегию обновления refresh token'а на нескольких устройствах. Если хранить в базе данных токен и обновлять его каждый раз по требованию клиента, то на устройствах необходимо будет постоянно проходить процесс аутентификации. С другой стороны, если токен не обновлять, то при его краже или наступлении expires_in он станет невалидным, что повлечёт за собой процесс аутентификации. Подскажите верную стратегию обновления refresh token'a используя JWT для нескольких устройств. Заранее спасибо!

Answer 1

[Сергей Горностаев]

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

Comments

[unroot]

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

[Сергей Горностаев]

unroot, будет пользоваться полчаса, пока не истекут все выданные токены доступа:

1. Злоумышленник крадёт токен обновления
   
2. Злоумышленник использует его для получения токена доступа
   
3. Происходит обновление обоих токенов
   
4. Пользователь использует старый токен обновления и получает отлуп
   
5. Пользователь перелогинивается и украденный токен становится невалидным
   

[unroot]

Сергей Горностаев, извините, затупил. Спасибо большое за ответ

[Александр Панков]

unroot
@sergey-gornostaev

1) В базе у нас есть таблица
user_id, fingerprint, refresh_token, exp_at
те строка соответствия id юзера, какого-то ключа устройства (фингерпринт) и сам рефреш-токен с датой валидности

2) злоумышленник украл наши токеныи шлет запрос на обновление токена (шлет ведь сразу оба токена?)
из access_token мы получаем (user_id + fingerprint), хоть он и просрочен
смотрим рефреш токен в базе
те ищем строку user_id + fingerprint + refresh_token
есть такая строка (логи нашего настоящего клиента ее туда поместил)

3) для злоумышленника генерируем новый аксес-токен и новый рефреш-токен обновляем в бд запись
user_id + fingerprint + refresh_token
злоумышленник всем этим прекрасно пользуется неограниченное время

4) наш пользователь аналогично пользуется своим аксес-токен, но он у него заканчивается и он шлет запрос обновления

5) мы в базе ищем его рефреш токен
user_id + fingerprint + refresh_token
и не находим, так как его обновил наш злоумышленник со соим фингерпринт, используя ранее украденные токены

6) соответсвенно клиента кидаем на авторизацию, он логинится и получает свои 2 токена, а злоумышленник продолжает пользоваться токенами. Приложение думает что просто клиент наш авторизован с 2ух устройств сразу и все в норме

Что-то я н понимаю, подскажите пожалуйста где ошибка?