Имеет ли смысл хранить refresh-токены?
В некоторых руководствах рекомендуется хранить выданные пользователю refresh-токены и сравнивать присланный пользователем токен с сохраненными в базе.
Есть ли в этом смысл? Поскольку в теории токен могут, скорее, украсть, нежели "подделать".
Дополнительно:
Refresh-токены хранят для проверки на повторное использование. При первом использовании ставится пометка, при попытке повторного использования блокируются все refresh-токены пользователя. При следующем обновлении с любого клиента данного пользователя потребуется полная аутентификация. Можно хранить не весь токен, а только uid токена и id пользователя.
Это слишком общий вопрос.
В целом, хранить сами токены не стоит ни в каком случае, для сравнения всегда достаточно хранить хеш.
В случае если вы используете JWS, хранение токенов может потребоваться чтобы иметь возможность отозвать токены при завершении сессии пользователем. Обычно хранится не сам токен, и даже не хеш, а идентификатор сеанса. При этом можно хранить либо список активных сессий либо наоборот список отозванных (в течении времени жизни рефреш токена). Фактически это убивает все преимущества JWS, но другого способа завершить сеанс нет, это глобальная проблема JWS. Поэтому использовать JWS для рефреш токенов в целом не очень разумно.
Про запрет повторного использования вам ответили, но в целом такой запрет является опциональным, в большинстве реализаций OAuth2 новый рефреш не возвращается и старый токен остается действительным.
В случае если вы не используете JWS, а генерируете случайные токены, вам в любом случае надо их хранить (точнее их хеши), т.к. вы будете сравнивать переданный токен с хранимым.
-
всегда достаточно хранить хеш
Это само собой. Не стал указывать, т.к. к вопросу прямого отношения не имеет.
в любом случае надо их хранить (точнее их хеши)
Пока вижу единственную причину в ответе выше.
- VolgaVolga, при хранении хеша нет рисков "украсть", о которых вы пишете.
Самая частая причина хранения рефреша в том, что для рефрешей обычно не используется JWS, а используется случайная строка, соответственно переданный токен сравнивается с хранимым в базе. JWS выгодно использовать только для access токенов, потому что их требуется проверять гораздо чаще и JWS позволяет делать это децентрализовано без запроса к базе + нет необходимости их отзывать, с чем у JWS проблемы. Рефреш токен всегда проверяется централизовано, поэтому каких-либо преимуществ у JWS нет а проблемы с отзывом есть
- Владимир Дубровин,
при хранении хеша нет рисков "украсть", о которых вы пишете.
Под "украсть" я понимал украсть у пользователя, а не из базы.
используется случайная строка
Не совсем. Токен подписывается на сервере и "левый" или измененный токен не пройдет проверку.
- VolgaVolga, может просто тебе надо сделать так что бы небыло доступа к токенам из js? просто хранить их в куках с флагом httpOnly: true
- szQocks, возможно. Но смущает, что access-токен будет гоняться со всеми запросами подряд, а не только с теми, которые требуют авторизации.
- > Не совсем. Токен подписывается на сервере и "левый" или измененный токен не пройдет проверку.
Вы путаете две разных технологии. JWS (подписаный JWT) позволяет не хранить токены в базе. Альтернатива это не использовать подпись и вместо этого хранить токены в базе (предпочтительней в виде хешей) и сверять их по значению в базе, а не по подписи. Подпись в таком случае не требуется. Так вот для refresh-токенов обычно используется именно второй подход по причинам описаным выше.
- Храните рефреш токен в куке выделенного поддомена с o2 провайдером на стороне клиента, на стороне сервера храните в базе хешем.
Аксесс токен нормально делать JWS и можно хранить и не в куке, но всю статику в любом случае лучше унести на отдельный домен. Анонимные концы тоже можно унести на отдельный домен с CORS'ом. - Владимир Дубровин,
Вы путаете две разных технологии.
Да, действительно.
можно хранить либо список активных сессий либо наоборот список отозванных
это убивает все преимущества JWS
Верно понимаю, что убивает преимущества тем, что приходится лезть в базу?
- > Верно понимаю, что убивает преимущества тем, что приходится лезть в базу?
да, все так
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Хранение refresh-токенов может быть полезным в определенных сценариях, особенно если вы работаете с API, требующим авторизации. Refresh-токены обычно используются для обновления access-токенов, которые предоставляют доступ к защищенным ресурсам.
Основное преимущество хранения refresh-токенов заключается в том, что они могут быть использованы для получения новых access-токенов без необходимости повторной аутентификации пользователя. Это удобно для пользователей, так как им не нужно вводить логин и пароль каждый раз, когда их access-токен истекает.
Однако, есть некоторые риски, связанные с хранением refresh-токенов. Если злоумышленник получит доступ к refresh-токену, он сможет получить новый access-токен и получить доступ к защищенным данным. Поэтому важно хранить refresh-токены в безопасном месте, например, в зашифрованном виде или в защищенном хранилище.
Также стоит учитывать, что refresh-токены обычно имеют длительный срок действия, поэтому их следует аккуратно обрабатывать и обновлять периодически, чтобы уменьшить риски безопасности.
В целом, хранение refresh-токенов имеет смысл, если вы понимаете риски и принимаете меры по обеспечению безопасности. Важно оценить конкретные потребности вашего проекта и принять решение на основе конкретных обстоятельств.