Комментарии 26
Немного не понятен механизм проверки на компрометацию рефреш токена. Не могли бы, подсказать где прочитать или может в двух словах?
На самом деле смысл такой.
У вас есть Access Token (в нашем случае JWT) и Refresh Token (любой).
Access Token — короткоживущий (например, час; можно реализовать через exp), его можно не записывать в базу, проверяется только по подписи.
Refresh Token — живет дольше (например, 30 дней), записан в базу и проверяется по наличию в ней.
Когда нужно сгенерировать новый Access Token:
— берём Refresh Token из запроса
— ищем его в базе и получаем код связанного с ним пользователя
— удаляем текущий Refresh Token из базы
— генерируем новую пару токенов
— новый Refresh Token записываем в базу.
Если кто-то украдет из клиентского приложения только Access Token, он проживет тот же час и протухнет.
Если кто-то украдет оба токена, то через час одна копия приложения успешно получит новую пару токенов, а вторую выкинет, так как такого Refresh Token уже нет в базе.
Также довольно сложно обсуждать рефреш токен без обсуждения токена со sliding expiration, потому-что вроде как это два подхода к решению проблемы короткой жизни access token.
Если коротко, то для решения этой проблемы можно использовать либо долгоживущие access токены, либо токены со sliding expiration. Это значит, что при каждом обращении к серверу время жизни токена обновляется. То есть он протухает, например, за 10 минут, но именно за 10 минут бездействия.
Проблема такого подхода в том, что если пользователя удалять или урежут его права, то он будет продолжать ходить с существующим access токеном все-еще со старыми правами неограниченное время. Для этого и ввели refresh токены, т.к. чтобы дропануть пользователя, достаточно просто удалить его из бд
Если кто-то украдет оба токена, то через час одна копия приложения успешно получит новую пару токенов, а вторую выкинет, так как такого Refresh Token уже нет в базе.
Так а если обновится утекший токен? У злоумышленника будет рабочий токен, хоть и не надолго.
deleted
Не знаю, в статье просто как-то этот процесс не очень подробно описан (а в комментарии передать тяжело)
Не совсем по теме вопрос.
HS256 vs RS256
Если на стороне клиента не требуется проверять подпись,
то что дает (в плане безопасности, скорости и т.д.) rs256?
Имеет ли смысл ограничиться HS512?
Спасибо.
Если прикладной сервер взломают, то всё равно не смогут генерировать корректно подписанные токены. Сервер авторизации при этом может быть один на группу прикладных и, соответственно, более защищённым, поскольку к нему обращаются только прикладные серверы.
Условия:
Авторизации как таковой у меня нет.
Я использую JWT, разумеется, чтобы не хранить у себя состояние, которое я не могу восстановить, если я его не храню или мне его не вернут.
Отдельного сервиса с ключом у меня тоже нет, можно считать, что каждый сервис хранит ключ у себя и вопрос взлома не стоит.
Использование:
Один раз я отдаю токен с данными клиенту, второй раз, если они его устраивают,
он мне возвращает токен, я проверяю время и подпись, затем применяю эти данные.
Вывод:
Не имея в наличие отдельного сервиса, который создавал бы токены, выгоды в RS256 я не вижу.(В моем случае)
Без авторизации всем пользователям доступнs все данные и функции и нет смысла в подписи токена. Полезная же нагрузка без кодирования в base64 займёт в полтора раза меньше места.
Смотря как настроено.
Самый лучший вариант — показывать текущие сессии пользователя, с IP и GeoIP-данными, и иметь возможность закрыть любую из них (удалив Refresh Token).
Т.е. основной сценарий использования такой: клиент запрашивает ресурс с JWT и если сервер возвращает ошибку «Токен истек», тогда клиент отправляет RT и нам приходит новая пара JWT+RT. С новым JWT мы снова можем обращаться к приватным ресурсам.
Или я неправильно понял и имелась ввиду именно такая схема?
Добавляем Refresh Token