DP
два комплекта
Size: a a a
2019 December 25
DP
один приватный на сервере, другой на клиенте
I
приватный ключ есть только у сервиса авторизации. всем остальным раздаёшь публичный ключ. на фронте вообще не нужны ключи
А JWT разве не ведет к возможности угона токена? Фронтэндеры - тоже люди, тоже могут ошибиться и добавить что-то в скрипты с непроверенного источника. Тогда это самое будет иметь доступ почти ко всей информации на странице, и отправлять ее куда-то насторону.
ВС
Так тут и не только jwt утечь может, id сессии в этом плане ничем не отличается
I
Так тут и не только jwt утечь может, id сессии в этом плане ничем не отличается
если он HttpOnly, то как он утечет? к нему JS доступа не имеет
S
для этого используется два токена. одним аутентифицируешься, у него короткий срок жизни (1-10 минут), вторым получаешь новый токен для аутентификации, когда у него время жизни истекло. второй надо хранить надёжно. угонят первый токен - скорее всего даже воспользоаться не успеют - за несколько минут превращается в бесполезный набор байт
I
для этого используется два токена. одним аутентифицируешься, у него короткий срок жизни (1-10 минут), вторым получаешь новый токен для аутентификации, когда у него время жизни истекло. второй надо хранить надёжно. угонят первый токен - скорее всего даже воспользоаться не успеют - за несколько минут превращается в бесполезный набор байт
а чем это лучше сессии с хттп-онли?
ВС
Тем, что хранить сессию не надо
S
с сессией чтобы проверить, что на твой сервис пришёл запрос от васи пупкина, твоему сервису нужно сходить на узел, хранящий сессии и данные о пользователях. это время, это ресурсы. с асимметричным jwt любой твой сервис всегда может быть уверен, что запрос от васи пупкина и токен ему точно выдал доверенный сервис, никуда не ходя при этом
C
оп оп за jwt в локал сторейдже трём?