Где лучше хранить JWT?

Здравствуйте!
Задался вопросом, всё же есть ли "серебряная пуля" в данном вопросе? localStorage или Cookie? Или что-то еще?
На текущий момент я храню JWT в зашифрованных cookie, параллельно со стороны сервера передаю токен в Authorization в Header.
Пример кода выложил на Git
  • Вопрос задан
  • 4339 просмотров
Решения вопроса 1
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Где угодно, но в зашифрованном виде и с флагами secure и http-only.

Доп.защита: Можно разместить в localStorage контрольную сумму полученного токена и тупо проверять его наличие в js и на соответствие конкретному значению, привязанному к клиенту. Любое обращение без подписи запроса этой КС - фиксировать как нарушение и блокировать учётку.

Главное - привяжите токен к клиенту через fingerprint2.js при двухфакторной аутентификации клиента.

Чтобы при хищении даже всех кук (например, через сторонние расширения), они были бы попросту бесполезны, "отпечаток" клиента передавайте при:
1. Авторизации (только двухфакторная аутентификация: почта, смс, GA и т.п.),
2. При смене ip-адреса
3. При смене user-agent
4. По истечению срока давности
И обязательно это всё через шифрование своим публичным "ключом" сервера (помимо https!).
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
bingo347
@bingo347
Crazy on performance...
В принципе это относится не только к JWT, но и к любым данным, которые критично не дасть украсть.
Такие данные лучше всего хранить в secure http-only cookie. С secure думаю понятно, такая кука будет отправляться на сервер только по https, что снизит вероятность угона путем подслушивания трафика. А вот с http-only причина та же, почему не стоит использовать localStorage - не http-only кука доступна из JS, из любого JS загруженного на странице.
Что в этом плохого? Вы уверены во всех скриптах, подключенных к Вашей странице? А если сторонний сервер был взломан? А если у пользователя стоит вредоносное расширение, подменяющее определенные скрипты на всех сайтах? Соберет такой вредонос из localStorage токены Ваших пользователей, а Вам потом с ними разбираться, почему их взломали.
Ответ написан
@Rusilius
+ к тому, что сказали. Нужно ограничивать время жизни токена. И если даже уведут, то есть вероятность не успеть им воспользоваться. Такой токен обычно называют access token. И он сам себя продлить никак не должен уметь.
Ответ написан
Комментировать
Sanes
@Sanes
SessionStorage + HTTPS и TTL контролировать на сервере.
Может оверхед конечно. Но ничего лучше для параноиков пока не придумано.
Ответ написан
@nikandfor
Токены вроде лучше не класть в куки, чтобы вредоносный javascript не мог ими воспользоваться.
Ответ написан
Ваш ответ на вопрос

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

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