DG
Суть в том, что если JWT у вас кто-то утащил, то он сможет творить беспредел только вот эти 30 минут, пока JWT не станет инвалидным
Size: a a a
2020 October 09
DG
да эт понятно всё. затык был в refresh-token. разобрался вроде..
У меня есть готовая реализация JWT на Yii2. Сами кодили все.
DG
Сначала тоже не знали с какой стороны подойти. Думали что там все значительно сложнее, чем оно есть на самого деле. На деле оказалось все предельно просто
DG
JWT нужен для каждого запроса. Refresh только для получения нового JWT, когда истёк старый
DS
Сначала тоже не знали с какой стороны подойти. Думали что там все значительно сложнее, чем оно есть на самого деле. На деле оказалось все предельно просто
Что там сложного. Жвт - это аналог сессии, только сессионные данные хранятся в токене на клиенте, а не на сервере в сессионном хранилище, поэтому есть некие ограничения для чувствительной информации.
Д
JWT нужен для каждого запроса. Refresh только для получения нового JWT, когда истёк старый
вот с refresh и запутался. хранить его в базе, или не хранить. в целом, если реализовывать список сессий активных/неактивных, с возможностью убить сессию - можно в базу писать его
DG
Хранить в базе
DS
вот с refresh и запутался. хранить его в базе, или не хранить. в целом, если реализовывать список сессий активных/неактивных, с возможностью убить сессию - можно в базу писать его
Просто хранить - мало, если ты пишешь приложение такого уровня, что там очень строго с безопасностью, то надо хранить и дополнительные данные по рефрешу. Я обычно ограничиваюсь записью в лог, кто когда и что рефрешил.
DG
Причём отношение hasMany, потому как пользователь может быть залогинен с вебморды, и через апи с какого-нибудь телефона, планшета, и чего угодно ещё. И делают опцию разлогиниться на всех устройствах, которая должна убить в базе все эти рефреш токены
Д
ну вот да. вроде разобрался.
Д
спасибо!
DG
Сам JWT при этом хранить не надо
DG
Он прилетает от клиента
DS
Причём отношение hasMany, потому как пользователь может быть залогинен с вебморды, и через апи с какого-нибудь телефона, планшета, и чего угодно ещё. И делают опцию разлогиниться на всех устройствах, которая должна убить в базе все эти рефреш токены
Если такой функционал есть, то да, только хранить все токены на сервере, но опять же это противоречит сути жвт - не лазать лишний раз в базу.
DG
Берёшь из него открытый пейлоад, подписываешь его на сервере, и сравниваешь с подписью которая прилетела в JWT
DG
Если такой функционал есть, то да, только хранить все токены на сервере, но опять же это противоречит сути жвт - не лазать лишний раз в базу.
Не лазить лишний раз на каждый запрос. Это да. Лазить только когда нужен рефреш
DG
Тут уже компромис. Секьюрность или экономия запросов к БД. Ты же можешь и 24 часа срок жизни сделать у JWT. Но тогда это будут те же кукисы. Хотя вру. Все равно это будут не кукисы
DS
Не лазить лишний раз на каждый запрос. Это да. Лазить только когда нужен рефреш
Ну, в yii это не сильно акиуально, как минимум для identity в базу слазить надо)
DG
JWT на клиенте нигде не хранится. Только в памяти приложения
DG
Ее сложнее увести оттуда