куки авторизацию? 🙂
В куки класть жвт? ☺️
Единственный верный способ при аутентификации браузерного клиента
Кто сказал и почему?
Потому что в ином случае любой npm-пакет имеет к нему доступ
куки единственная сущность к которой можно явно запретить доступ для скриптов
localStorage, sessionStorage и прочие не предназначены для чувствительных данных, потому что видны скриптам. А видимость кук можно ограничить только серверами
1) А в чём проблема хранить access токен в памяти ? (в нашем случае - во временной переменной) Назовите мне хоть один вредоносный скрипт, который кроме хранилищ парсит все переменные приложения 2) Как будете без доступа к токену проверять его время жизни для отправки запроса на обновление ? 3) Как вы себе представляете работу с куками в мобильных приложениях ?
А парсить все переменные и не нужно, прежде чем попасть в память этот токен должен как-то прилететь - либо в незащищенную куку, либо заголовком либо в теле ответа. Собственно там и есть возможность его поймать. Так что декламатор выше прав - только httpOnly + secure cookie
Пожалуй соглашусь. Плюс через куки банально намного удобней. Тогда вопрос - а как фронт должен понимать, что ему запрос на refresh надо отправить ? Когда в ответе приходит что токен недействителен ?
Зачем вообще jwt, если сессия уже запущена и пользователь и так аутентифицируется?
Чтобы на каждом запросе не лазить в базу, например за ролью пользователя
jwt нужен когда у тебя несколько сервисов, т.к. в нем ты можешь зашить основную инфу (которая тебе нужна) о юзере и тебе не придется на каждый хит слать запрос в бд или сервис юзеров/аутентификации.
Сохрани все, что кодируешь в jwt - в сессию, зачем придумывать велик) Если нужно stateless, то сессии не нужны
Это можно в мапу засунуть. Я насколько понимаю JWT хорош там где много серверов и когда нет необходимости в репликации обширных данных пользователя.
А если роль поменялась?)
Только если эта инфа не может измениться
Обычно у токена маленькое время жизни. После рефшера будет новая роль
Обсуждают сегодня