Как обновлять токены авторизации для нескольких устройств?

Question

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

Здравствуйте, подскажите по логике авторизации по access\refresh токенам для нескольких устройств одного пользователя? не могу понять как инвалидировать украденные токены и не навредить реальному клиенту?
у меня есть ход мыслей и он такой

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

- access_token (user_id + fingerptint) - в базе его не храним, в нагрузке идентификатор клиента и его устрйокста
- refresh_token - храним вместе с user_id, fingerprint, exp_at

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ух устройств сразу и все в норме

В итоге мы имеем доступы у всех и с точки зрения приложения все прекрасно, я понимаю что можно в ЛК клиента сделать вкладку "Ваши сессии" и выводить все кроме текущей, чтобы он мог сам из удалить и закрыть доступ у злоумышленника, он если он украл один раз все его токены, то украдет и второй раз

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

Answer 1

[Rsa97]

При использовании refresh-токен помечается в базе как использованный. При попытке повторно использовать тот же токен удаляются все refresh-токены пользователя и запрашивается логин/пароль.
Refresh-токен удаляется из базы после истечения срока его жизни.

Comments

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

Rsa97 верно, у меня нигде противоположного не сказано

украли токены
с их помощью обновили и получили новые

клиент уже не может обновить свои (его рефреш затер злоумышленник) и его "разлогинивает" так скажем, а злоумышленник продолжает сидеть в учетке настоящего клиента

[Rsa97]

Александр Панков, Сорри, неверно написал. Поменял ответ.

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

Rsa97, Хм, предложенный вами подход самый удобный из всех что я нагуглил\напридумывал, спасибо, надо будет над этим подумать

[Дмитрий Свиридов]

Александр Панков, да, но если с фронтенда будут сделаны асинхронные запросы, то эта схема не будет работать

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

Дмитрий Свиридов, а почему?

[Дмитрий Свиридов]

Александр Панков, часто (везде, где я видел) реализуется примерно такая логика: если сервер вернул 401, то идём рефрешить токены. Если и рефреш токенов вернул 401, то, значит, кидаем юзера на форму авторизации.

При такой схеме если запросы на сервер отправляются одновременно пачкой, то в какой-то момент может возникать ситуация, что все они получат 401, т.к. протух access-токен, который они передавали в заголовке - и все они пойдут рефрешить токены. Соответственно первый же прилетевший запрос пометит refresh-токен использованным, а остальные уже не смогут зарефрешиться из-за этого и вернут 401. Соответственно, юзера разлогинит. Есть два варианта решения:

1. Либо на фронтенде отслеживать, чтобы строго один запрос мог рефрешить токены одновременно
   
2. Или же на сервере не помечать рефреш-токен использованным сразу же при рефреше, а оставлять ему ещё секунд 5 жизни (чтобы все асинхронные запросы гарантированно успели зарефрешиться). То есть ставить ему какой-нибудь exp_at = now() + '5 sec'.
   

[Rsa97]

Дмитрий Свиридов, Такое на фронте (как минимум, на JS) решается достаточно легко. Если запрос получил 401, то он проверяет, не начал ли какой-то другой запрос процедуру обновления токена. Если нет, то поднимает флаг и сам начинает обновление. Если да, то дожидается опускания флага и использует обновлённый токен.

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

Rsa97, я верно понимаю что фингерпринт не нужен вообще?
даже если несколько устройств, ведь для каждого "входа" сервер и клиент имеет рефреш токен и он однозначно определяет сессию?

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

1) клиент логинится получает пару токенов (рефреш хрнаим в базе)
2) клеит юзает сой аксес и обновляет свою пару через рефреш (мы а базе рефреш старый помечаем использованный, создаем новый рефреш когда он нам прилетает)

никаких фингерпринтов, даже если будет 10 устройств - они пересекаться не будут

Допустим хакер крадет и рефреш и акксес
1) ходит с акксес токеном
2) рефрешит его (мы в базе старый помечаем использованным) новый ему даем
3) клиент юзает сой рефреш м по бзе видим что он у нас уже использованный - выходим отовсюду. те удаляем рефреш токены

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

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

единственное что
если храним с рефрешем еще и фингерпринт
то если у нас хакер крадет токены и пытается обновить их
то его фингерпринтбудет другой. а мы сверяем строго рефреш + фингерпринт
и мы ему ничего не выписываем и сразу обрубаем. те он пользуется тлоько 15 минут нашим аксесом, больше преимуществ нет, или они есть?

с условием что в playload аксеса у нас только user_id и больше никаких данных

единственное что смущает - храннеие рефрешев, получается для 1ого клиента мы храним все его страые рефреши, которые каждые 15 минут обновляются, а если клиентов будет 100к и каждые 15 минут 100к записей в БД новых (новые рефреш + старые рефреш)

[Rsa97]

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

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

Rsa97, не да jsом
https://fingerprintjs.github.io/fingerprintjs/

как тут пишут https://gist.github.com/zmts/802dc9c3510d79fd40f9d...

[Rsa97]

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

Что такое fingerprint? ... Это хеш сгенерированный js'ом на базе неких уникальных параметров/компонентов браузера.

Всё, что генерируется на клиенте, можно подделать и передать фингерпринт жертвы вместо своего.