Виды авторизации: сессии, JWT-токены. Для чего нужны сессии? Как работает JWT? (+ разбор ошибки)
Vložit
- čas přidán 25. 06. 2024
- Привет! Это видео является частью моей лекции в рамках проекта "ITMO.Mentors". Сегодня поговорим о самом процессе авторизации, о сессиях и токенах, разберём ошибку из прошлого ролика.
Полезные ссылки:
Аннотация и презентация к ролику: t.me/davidobryakov/1003
Мой телеграм-канал: t.me/davidobryakov
Поставить звёздочки на гитхабе: github.com/kantegory
Сессии в Django: mzl.la/3k0hCsx
Авторизация: mzl.la/3506nfo
Пять простых шагов для понимания JWT: habr.com/ru/post/340146/
Видео про JWT: • JWT. Часть 1. Теория
Где хранить JWT? habr.com/ru/post/502702/
JSON Web Token: ru.wikipedia.org/wiki/JSON_We...
Зачем Refresh Token, если есть Access? habr.com/ru/company/Voximplan...
Таймкоды:
00:00 Вступление
00:05 Точки над Ё
02:16 Сессии
06:39 Токены
11:08 Что такое JWT?
13:15 Пара токенов
14:36 Что почитать?
15:22 Разбор ошибки
Все четко и по делу. Хорошо расписано и понятно. Лайк и подписка
Время жизни токена устанавливается на стороне сервера кодером, ну и конечно устанавливаются те числа которые нужны по логике кодера ))
Спасибо за видео!
Спасибо. Кратко, ёмко, понятно))
Большое спасибо за информацию
Благодарю
спасибо за видео)
Мне здорово помогла эта инфа! И прикрепленная тоже.
спасибо мужик, удач во всем (сообщение более пяти слов для алгоритма ютьюба))
Спасибо!
Очень круто
Спасибо!
Нет ничего невозможного, все зависит от времени, мастерства и желания
12:40 в итоге получаем особый вид вредительства - "разлогинивание пользователей каждую минуту" =)
14:30 ошибка. если истек refresh token, то это разлогинивание без иных вариантов. Для того, чтоб избежать разлогинивания, за определенный период времени перед истечением refresh token необходимо отправить запрос на его обновление. Например, если сам токен живет месяц, то за неделю до его истечения обновляем refresh token
Про токены: если refresh токен получил злоумышленник, но он может сам создать токен. Поэтому сторонние плагины при получении доступа к access token, могут получить доступ и к refresh токену.
Путь решения проблемы автор ролика упоминул, - разлогиниться.
Уважаемый друг! Спасибо за видиеоурок. Скажи пожалуйста как можно решить следующую аутентификацию когда появляются на телефоне два разные токена при авторизации в виде семизначными цифрами и второе шестизначными цифрами на короткое время и просят нажать кнопку отправить и исчезает. А на следующем этапе появляется один токен с другими шестизначными цифрами и требует записать второго токена семизначного цифра. Как можно решить такую аутентификацию? Помоги если сможешь.
Видео классное, но jwt токен можно подменить, если ключ шифрования не был достаточно надежен, можно забрутфорсить
Спасибо за ролик. Но всё-таки как на сервере "расшифровывается" содержимое jwt, если sha256 - необратимое шифрование?
В sha256 хэшируется только подпись токена. Сам токен просто закодирован в base64.
Сессия и токен это не виды авторизации. Сессия это единица учета пользователя в системе. А токен это расширенный формат этой единицы учёта, в нём есть заявки пользователя. В обоих случаях, сама авторизация происходит потом, на основе этой единицы учёта. Те же jwt токены так же нуждаются в сессиях и их управлении. Черный список не решает проблемы токенов, потому как кроме всего прочего необходимо вести учёт того сколько раз пользователь зашел под одним и тем же аккаунтом, иначе шаренный аккаунт будет юзаться всеми кому не лень. jwt был придуман для того чтобы разгрузить процесс авторизации(проверки пермишенов), а не для того чтобы заменить сессии.
Топ видео
Какой в едренефене доступ к обновляемому токену? Обновляемый токен является одноразовым и если злоумышленик его получает, то у тебя получается проблема, так как ты получишь уведомление, о том что твой токен неверен"протух".
Под обновляемым токеном имеется ввиду access token? Или refresh token?
Access token живёт, как правило, около 5 минут и одноразовым не является. Кроме того, никто не запрещает пользователю логиниться с нескольких устройств и в случае ошибки обновления access token'а - пользователя просто разлогинит и он зайдёт заново и получит новую пару access и refresh, что вообще никак не повлияет на ситуацию, когда у злоумышленника оказался refresh token, потому что он может без особых проблем сидеть и обновлять его, выписывая новую пару токенов.
Для решения таких проблем токены обычно выносят в куки, защищённые от вмешательства со стороны JS, чтобы их украсть было не такой простой задачей.
На практике можно болт положить на устройство jwt токена за 3-4 года работая с микросервисами где токены активно юзаются ни разу об этом не думал так мельком гуглил шо оно такое вначале и благополучно пошел дальше, но на каждом собесе это цепляют.. - спрашивается вот зачем каждому разработчику знать эту подноготную?? - если ты не работаешь над auth модулем или чем то где вот именно эти знания реально нужны - как впрочем и др топики из этой же серии: сборка мусора - мне глубоко до 3,14 как оно там собирает мусор - сборку мусора для того и придумали что б я об этом не парился. 0,1% задач где это важно в остальных случаях это только нагружает мозг и замедляет процесс написания кода - ведь мозгу приходится процессить мне создать как обычно класс или всё-таки структуру.. - я так понял что мир полон задротов которые хотят всех под свою гребенку расчесать когда спрашиваешь интервьювера а зачем мне под ваши реквайрменты знать то что ты спрашиваещь - в 9 из 10 случаев человек меньжуется ну типа я общий уровень проверяю..
Да, некоторые спрашивают про энциклопедические данные, которых за несколько лет возможно ни разу не приходилось использовать. Не уж то так прикольно работать с задротами в команде. Ведь тех детали всегда можно подсмотреть в нужный момент
за 10 процентов сложной работы платят 70 процентов денег в IT
ничего непонятно =(
После 9 минут просмотра ни слова про oayth и собственно jwt. Заголовок кликбейтный, дизлайк
есть же таймкоды :)
Нести откровенную чушь важным тоном и учить людей тому, в чем сам не разбираешься - это особый скилл.
«Сессия хранится в куках» - восхитительно
Разумеется, я имел ввиду токен, по которому происходит авторизация. И чаще всего, этот самый токен действительно хранится в куках. Понятно, что сама по себе сессия хранится в базе данных и привязывается к определённому пользователю, но гуляя между фронтом и бэком -- она находится в куках (в подавляющем большинстве случаев)
Недавно на сайте вконтакте уаидел в payload мои данные в нешифрованном виде ,как такое возможно?
Спасибо за ролик. Но всё-таки как на сервере "расшифровывается" содержимое jwt, если sha256 - необратимое шифрование?
Всё не совсем так. В sha-256 шифруется только часть, которая является подписью сервера, остальное содержимое токена просто закодировано в base64.
@@dobryakov , хэштруется, а не шифруется. Т.е. это своего рода контрольная сумма данных (в данном случае заголовка и тела токена), только криптографически стойкая. Эта контрольная сумма потом шифруется на ключе подписи сервера авторизации (т.к. сервер данных находится в цепочке доверия с сервером авторизации, то у сервера данных есть ключ проверки подписи сервера авторизации). На стороне сервера данных происходит расшифрование подписи на ключе проверки подписи, получаем хэш, который сравниваем с результатом хэширования заголовка и тела токена. При совпадении этих хэшей и получаем подтверждение подлинности и неизменности данных в токене. Если уж рассказываете про безопасность и, упаси Бог, употребляете слова: ключ, шифрование, подпись, хеширование, - то советую разобраться в этом поглубже, чтобы подобные вопросы в комментариях не возникали.