я отправлял только access token клиенту, c refresh даже не сталкивался, по видео можно сразу понять как его написать и пользоваться сразу двумя токенами для большей безопасности, но как правило refresh не всегда нужен, все понятно и кратко, спасибо! интересно какие аналоги JWT токену есть?
какой смысл их хешировать? Если сервер не знает пароля... а если ты посылаешь готовый хеш который хранится в базе данных - то это и есть пароль который ты в открытом виде передаешь а то что ты его ка-то там с помощью чего-то создаешь никого не интересует. Как-то закодировать наверно есть смысл а хешировать точно нет...
Сразу можно проверять, но тогда сервер не сможет отправить новую сгенерированную пару клиенту, ввиду разных запросов) Так как например на GET /users или POST /add-to-cart, при экспирации токена и проверке рефреш токена, сервер должен будет отправить либо новые ключи, или данные)
да по моему лучше дальше что-то продолжать показывать, нельзя же быть совсем с дыркой в голове и не проверять посылаемые токены... наверняка кто-то левый присылает пусть разбирается в мусоре что ты ем шлешь пока не надоест ;)
Что-то все равно не понятно. Сказано, что access токеном может завладеть злоумышленник, поэтому создается еще и refresh токен, который будет обновлять access токен. Но что, если злоумышленник также завладеет и refresh токеном?
У рефреш токена обычно очень маленький срок, минут 15 например. В ситуации, когда злоумышленник перехватывает ваш рефреш токен и генерирует с помощью него новую пару(основной , рефреш) токенов, обычно вы продолжаете сессию и в процессе так же запрашиваете обновление токена, но из повторного запроса обновления по одному и тому же токену отзываются вообще все токены принадлежащие пользователю. +можно отслеживать на какой ip был выдан токен и накой ip просят новый и при не совпадении так же отзывать.
@@epishcom это у аксес токена время жизни 15-30 минут, а у рефреш токена где то от 2 недель до нескольких месяцев. Чем слушал? Обычно отслеживается откуда идет этот токен, поэтому если узнают твой рефреш токен, то сервер не позволит его юзать
В JWT есть шифрование, только автор этого не упомянул, т.к. не вникал в суть вопроса. В JWT можно именно зашифровать содержимое второй части токена (полезная нагрузка), а уже потом подписать описанным автором методом. Информация по алгоритму шифрования (наименование, входные параметры и т.д.) сохраняется в первой части токена (служебная информация). Потом уже это все кодируется в Base64-кодировке для передачи по HTTP (ну совсем не любит он бинарные данные, только текст).
@@eager4IT , не совсем))) Есть в программистской среде такое понятие, как "сигнатура метода" (информация, содержащая описание метода - имя, аргументы, тип возвращаемого результата и др.), так вот Ваш вариант конфликтует с этим. В большинстве случаев, конечно, это вина авто-перевода)))
Отличное объяснение и оформление. Сразу понял и запомнил всю информацию. Спасибо
Спасибо за фидбэк)
Наконец то нашла толковое объяснение темы jwt. Огромное спасибо😊
Пожалуйста)
+100
Du hast das Thema super verständlich gemacht.
Danke 🙂
Спасибо, очень четко!
Спасибо, очень полезно 👍
Пожалуйста 🙂
Спасибо большое
Пожалуйста)
я отправлял только access token клиенту, c refresh даже не сталкивался, по видео можно сразу понять как его написать и пользоваться сразу двумя токенами для большей безопасности, но как правило refresh не всегда нужен, все понятно и кратко, спасибо!
интересно какие аналоги JWT токену есть?
Спасибо за фидбек)
Аналогами могут быть абсолютно любые другие методы идентификации, вплоть до физических access ключей)
awesome!!! 🎉
Thanks)
на 4:35 забыл упомянуть, что перед тем как отправить данные на сервер, они хэшируются на клиенте, а так хороший видос, освежил память, спасибо
Конечно, все данные передаются в закрытом виде, благодарю)
какой смысл их хешировать? Если сервер не знает пароля... а если ты посылаешь готовый хеш который хранится в базе данных - то это и есть пароль который ты в открытом виде передаешь а то что ты его ка-то там с помощью чего-то создаешь никого не интересует. Как-то закодировать наверно есть смысл а хешировать точно нет...
А зпчем 401 на каждый устаревший запрос?
Не проще ли на 401 ввиду экспирации токена сразу проверить опцию с рефрешем?
Сразу можно проверять, но тогда сервер не сможет отправить новую сгенерированную пару клиенту, ввиду разных запросов)
Так как например на GET /users или POST /add-to-cart, при экспирации токена и проверке рефреш токена, сервер должен будет отправить либо новые ключи, или данные)
да по моему лучше дальше что-то продолжать показывать, нельзя же быть совсем с дыркой в голове и не проверять посылаемые токены... наверняка кто-то левый присылает пусть разбирается в мусоре что ты ем шлешь пока не надоест ;)
Что-то все равно не понятно. Сказано, что access токеном может завладеть злоумышленник, поэтому создается еще и refresh токен, который будет обновлять access токен. Но что, если злоумышленник также завладеет и refresh токеном?
У рефреш токена обычно очень маленький срок, минут 15 например. В ситуации, когда злоумышленник перехватывает ваш рефреш токен и генерирует с помощью него новую пару(основной , рефреш) токенов, обычно вы продолжаете сессию и в процессе так же запрашиваете обновление токена, но из повторного запроса обновления по одному и тому же токену отзываются вообще все токены принадлежащие пользователю. +можно отслеживать на какой ip был выдан токен и накой ip просят новый и при не совпадении так же отзывать.
конечно может, но ты его как-бы не так часто светишь как аксес... и вероятность меньше
Рефреш токен может быть установлен только через http, поэтому даже если его сопрут, то все равно не смогут воспользоваться)
@@eager4IT почему не сможет?
@@epishcom это у аксес токена время жизни 15-30 минут, а у рефреш токена где то от 2 недель до нескольких месяцев. Чем слушал?
Обычно отслеживается откуда идет этот токен, поэтому если узнают твой рефреш токен, то сервер не позволит его юзать
Такое чувство, что очень много пропустил, особенно что сервер который выдаёт токены как правило не тот, где лежит желанная штука
Это может быть один и тот же сервис или сервер, не имеет значения)
В JWT нет шифрования. Есть кодирование и хэширование.
Все верно. Ошибочно упомянул это в начале видео. В самом же объяснении используются правильные термины. Благодарю.
В JWT есть шифрование, только автор этого не упомянул, т.к. не вникал в суть вопроса. В JWT можно именно зашифровать содержимое второй части токена (полезная нагрузка), а уже потом подписать описанным автором методом. Информация по алгоритму шифрования (наименование, входные параметры и т.д.) сохраняется в первой части токена (служебная информация). Потом уже это все кодируется в Base64-кодировке для передачи по HTTP (ну совсем не любит он бинарные данные, только текст).
@@kolyuchkin http v2 любит ;)
т.е. нет шифрования? там даже есть поле какой алгоритм используется и приватный ключ нужен
@@kolyuchkin мне тоже кажется что есть смысл просто пользозваться aes-256-gcm например... зашифровано аес а как подпись gcm использовать
Дживити? Джот же
💯
Не "сигнатура", а "подпись".
Благодарю, но это одно и тоже)
@@eager4IT , не совсем))) Есть в программистской среде такое понятие, как "сигнатура метода" (информация, содержащая описание метода - имя, аргументы, тип возвращаемого результата и др.), так вот Ваш вариант конфликтует с этим. В большинстве случаев, конечно, это вина авто-перевода)))
Все верно, однако эта тема не про классы и методы)
@@eager4IT , а вне контекста программирования для чего эта тема?))
Что ты доебался, умник? Эти слова равноценны. Окно открой...
Отличное объяснение и оформление. Сразу понял и запомнил всю информацию. Спасибо
Спасибо за фидбэк)