Comments 9
Токены можно воспринимать как замену куки-файлов, имеющую несколько преимуществ перед ними.
Для меня звучит как «время можно воспринимать как замену часам». Ведь куки — это просто средство хранения информации. А JWT это та самая информация, которую надо где-то хранить.
А ещё в статье не увидел, в чём же преимущество использования JWT перед собственно паролем. Дело в ведь в ограничении успешного взлома по времени? Сломали JWT, а он заэкспайрился через пару часов.
UFO just landed and posted this here
Добавлю (не вам, а тем, кому эта информация может быть полезна в дополнение к вашей):
Хранение токена в куках само по себе даже с secure и httpOnly не защитит вас от самых банальных csrf-атак вроде вызова fetch с "{credentials: 'include'}" (но тут хоть как-то можно отбиться с помощью CORS) или даже просто стандартной формой с самым обычным POST где-то на просторах.
Поэтому не забывйте и про CSRF-токены, которые не должны храниться в куках.
Хранение токена в куках само по себе даже с secure и httpOnly не защитит вас от самых банальных csrf-атак вроде вызова fetch с "{credentials: 'include'}" (но тут хоть как-то можно отбиться с помощью CORS) или даже просто стандартной формой с самым обычным POST где-то на просторах.
Поэтому не забывйте и про CSRF-токены, которые не должны храниться в куках.
У JWT токена есть подпись, подписывать можно разными алгоритмами, можно выбрать из RSA («RS256», «RS512» ...). Создаёшь пару открытого и закрытого ключей, подписываешь закрытым, открытый отправляешь пользователю после успешной аутентификации вместе с подписанным токеном.
Единственный момент: если использовать связку Access и Refresh токенов, то при ответе сервера с новой парой токенов пользователю злоумышленник может перехватить эти данные и пользоваться ими сколько захочет, пока пользователь не узнает, что его взломали
Единственный момент: если использовать связку Access и Refresh токенов, то при ответе сервера с новой парой токенов пользователю злоумышленник может перехватить эти данные и пользоваться ими сколько захочет, пока пользователь не узнает, что его взломали
Раз уж вы все равно получаете пользователя на сервере, то почему для JWT выбрана именно почта и пароль? Гораздо логичнее было бы генерировать для каждого пользователя рандомную строку, которая бы шифровалась в JWT и использовалась для аутенификации.
Таким образом, если бы пользователю необходимо было бы разлогинить себя везде, то мы могли бы просто обновить рандомную строку.
Таким образом, если бы пользователю необходимо было бы разлогинить себя везде, то мы могли бы просто обновить рандомную строку.
ужастно осозновать и лицезреть на 1.3M использования, которые ставят jsonwebtoken c lodash зависимостью на борту, где можно было обойтись без него.
как пример https://www.npmjs.com/package/jose
Sign up to leave a comment.
Руководство по аутентификации в Node.js без passport.js и сторонних сервисов