JWT. Часть 1. Теория

[@АндрейСороковой-ю9ъ]

Круто объяснено! На пальцах, с картинками, все ясно )))

[@alexstatsenko1809]

Большое спасибо!! Я часа 2 читал что да как, не мог понять, а в видео все сразу стало ясно. Респект

[@АнтонВасильев-т2я]

Классный урок. Вот бы все так объясняли)

[@muborizDev]

Илья умеет объяснять сложные темы, простыми словами!

[@kinafermur]

на 1.5 отлично

[@МаксЕрмышев]

спасибо👍

[@myrichstory]

@@МаксЕрмышев а мне на 1.25х комфортно было

[@CrazyMongol123]

мне на 2

[@johnmarrewood]

@@CrazyMongol123 мне 0.5 норм

[@valeriyaleksandrovich2707]

Большое спасибо!! Отличное объяснение с наглядными схеами

[@КарлЛьвович-д8э]

СПАСИБО ОГРОМНОЕ за разъяснение 🤝

[@aleksandroff2757]

Шикарно объяснил! Подписываюсь

[@sivkaburka1062]

Досмотрел до конца

[@husankarimov7802]

ЭТО ШЕДЕВР

[@oleg_shulga]

Спасибо за видео!

[@eugeneburdin704]

Cпасибо ! Очень понятно!

[@IndexRTS]

14:46 а с чего это токены которые были у хакера станут не корректными? Ведь речь идет что - при условии что не используется хранилище токенов.

[@HyperTextTransferProtocol-l6m]

Тот же вопрос, автор сам сказал что нет механизма отзыва токенов

[@Anonimus_13]

Блэт, годный видос👍

[@azizkudaikulov993]

Спасибо, очень нужно и интересно

[@BuAjoyib]

очень понятно! спасибо за труд!

[@taran_dm]

Вот и пригодилось) Спасибо!

[@Костя-с5л8я]

Супер! Спасибо большое

[@Yornero]

Неплохо объяснено, плюс минус все понятно

[@smilesrg]

Спасибо за видео

[@АсланКосшанов]

Душевно объяснил, лайк и подписка сразу же таким пацанам

[@romansharpe1131]

Спасибо, очень классно все разъяснено

[@mirakmalsultanov3398]

супер, нет слов

[@Brometey]

Все шикарно объяснено, единственный момент, причем тут такены

[@count_of_pizza]

Спасибо за фильм, привет из Польши ;)

[@Ana-el3gk]

Thank you!

[@TheTexPro]

Спасибо большое!

[@ОстапБендер-и6п]

Не путайте Авторизацию и Аутентификацию!

[@aleksandrkravtsov8727]

не будем!

[@user-oh4xi2xb2d]

@@aleksandrkravtsov8727 :)

[@averv]

Вот именно, в видео рассказывается про аутентификацию. А еще небольшая каша с пониманием криптографии с открытым ключом

[@BraentR]

Спасибо

[@andreikan4894]

объясняете доходчиво! Советую смотреть на х2, очень тягучая манера говорить, а на ускоренном всё супер)

[@alimahmoudmansour9681]

спасибо!

[@ЕвгенийБорисов-е1ч]

Обьясните нафига токен передавать в Bearer заголовке тоесть палить токен? Его же нельзя передовать?

[@ДмитроПрищепа-д3я]

Если его, по вашим словам, нельзя передавать, то как вы собираетесь его использовать? Либо передаете в Authentication хедере, либо как HTTP-only куки. Но передать придется в любом случае, без этого сервак вас не узнает

[@ЕвгенийБорисов-е1ч]

@@ДмитроПрищепа-д3я Скажи JWT существует потому что AJAX запросы не шифруються как HTTP? И bearer токен имеет двойное назначение как токен авторизации и токен для подписей данных?

[@ДмитроПрищепа-д3я]

@@ЕвгенийБорисов-е1ч JWT(как и другие авторизационные токены) существует потому, что в REST приложениях не хранится состояние пользователей, поэтому и все данные для аутентификации нужно передавать вместе с запросами(не совсем полная история, конечно, в целом токенная атуентификация существует потому, что очень часто она удобнее, чем сессии). Кстати, HTTP не шифруется вообще, это просто протокол прикладного уровня над TCP. Шифруется уже расширенная его версия - HTTPS. К токенам это отношения не имеет. Bearer - тип схемы аутентификации в Authorization заголовке запроса, который означает, что после него идет такой токен, что подходит для доступа к ресурсам, защищенным по OAuth 2.0. Упрощенно говоря это значит, что такого токена полностью достаточно для получения наиболее полного доступа к ресурсу(наличие любого криптографического ключа у носителя токена не проверяется). Более подробно читать, собственно, спецификацию, а конкретно RFC 6750(datatracker.ietf.org/doc/html/rfc6750). Таким образом видно, что JWT полностью соответствует этой спецификации. Назначение Bearer токена - исключительно авторизация, по крайней мере в изначальном его смысле. Сами данные при этом могут, в зависимости от апи, передаваться в любом желаемом виде, хоть сырыми как query-параметры или в теле, хоть асимметрично шифрованными/как-то подписанными. Токен(и конкретно JWT тоже) к ним отношения не имеет, лишь к аутентификации пользователя, сделавшего запрос.

[@ЕвгенийБорисов-е1ч]

@@ДмитроПрищепа-д3я Ну вот я и слышал постоянно про JWT авторизацию и Bearer токен и у меня все смешалось и я запутался ну теперь чуть яснее

[@sergeyjacobi]

каким образм refresh токен хакера, после перелогина настоящего пользователя станет невалидным??

[@georgemanlove7411]

Пользователю будет выдана новая пара access-refresh токенов

[@nubosk]

@@georgemanlove7411 разве это обязательно должно убивать предыдущие пары? А как тогда держать авторизацию на нескольких устройствах? Ведь логин в одном будет убивать другой.

[@user-varmat]

интересно то что если хакер успел поменять логин и пароль пользователя, до истечения скрока токена, то и перелогинится пользователю будет сложнее и то если єта функциональность заимплеменчина в виде сброса пароля и т.д.

[@ВалежникНаш-с3э]

@@user-varmat Вот я тоже об этом подумал. А если например еще и поменял e-mail или телефон.

[@bogdanbabitskiy3345]

Добрый день, у меня 2 вопроса: 1) как лучше хранить refresh_token в mssql базе (В таблице юзера? И как хранить его дату истекания? То есть это должен быть какой то Json поле в таблице user`a и при получении access_token обновлять это поле всегда? Или можно как то подругому?)? 2) как на клиенте узнать что просрочен access_token (нужно ли для этого делать доп запросы? Или просто если при запросе пришел 401 ответ, сделать запрос на сервер аунтификации и авторизации и получить новый?) Заранее спасибо, застрял на этих вопросах, хочу сделать как лучше.

[@diperps4969]

2 отправь на клиент дополнительный заголовок, что срок годности токена истек

[@sergii.golota]

как злоумышленник сможет украсть access_token если мы к примеру используем HTTPS соединения?

[@dmytro_bro]

14:20 Каким образом рефреш токен который заполучил хакер становится не валидным? А что если честный пользователь логинится с двух устройств?

[@dmytro_bro]

Похоже нужно хранить все рефреш токены в БД и не удалять их, а при колизии нужно заблокировать все рефреш токены пользователя. При этом пользователю на всех устройствах и злоумышлинику нужно будет перелогинится.

[@deadorIT]

Тоже не понял. Он по логике с длинной жизнью, когда протухает акссес, рефреш генерит заново пару.

[@valeron_1337]

Но ведь у хакера останется не валидный рефреш токен. Он как минимум сможет постоянно пытаться его рефрешить что будет всегда сбивать все рефреш токены для реального пользователя. Да и вообще, для этого и красть то не нужно ничего. Зная userId пользователя можно генерить не валидные токены, отслылать их на ендпоинт для рефреша и тем самым сбивать все токены реально пользователя. Вот такое западло получается можно делать. Как-то не понятно с этим моментом.

[@dmytro_bro]

@@valeron_1337 1) Юзер логинится. 2) Мы создаем аксес токен и рефреш токен 3) сохраняем рефреш токен (токен, юзер айди, флаг использования, и время действия) 4) возвращаем токены 1) происходит рефреш запрос от юзера. 2) проверяем наличие токена в бд, проверяем что токен не использовался, проверяем что токен не протух. Если токен валидный то заменяем флаг на использован и выдаём новую пару токенов. Если токен не найден в бд или он просрочен то возвращаем 401. Если токен был использован, то скорее всего он был скомпрометирован и мы удаляем все рефреш токены (или заносим в бан, к примеру) И теперь единственный способ получить рефреш токен это авторизация. Так как мы удалили токены то колизия не произойдет повторно.

[@valeron_1337]

@@dmytro_bro Большое спасибо за разъяснение. Звучит надежно. Поделитесь пожалуйста ресурсом откуда почерпнули данное решение, если не сами до него дошли. Я просто сейчас посмотрел третий урок (Сервер) и исходя из него, описанный сценарий вполне возможен. То есть, получается как вы и написали в своем первом комментарии, сервер будет трактовать перелогиненого пользователя и хакера как две сессии на разных устройствах.

[@vasyadelyatunsky1816]

Это была песня из Безконечного лета в начале?

[@ИльяСосновский-ъ7и]

Что-то не очень понятен финт на 7:00. Получается они все равно общаются между собой, раз делят ключ? Но ведь мы хотели избавиться от этой связи?

[@jonnyradars]

Похоже, что просто количество необходимой коммуникации снизилось существенно. С JWT серверам авторизации и апи нужно общаться не каждый запрос пользователя к апи, а только в момент смены пары токенов.

[@blazheiko777]

спасибо, классно.

[@mihrankhachatryan3693]

Respect!!!

[@GlebMtb]

не хватило информации что значит проверить корректность этих данных на основании подписи 7:40

[@AdmAdm-ir3vv]

Прошу прощения за тупость, но на 6:58 - Каким образом секретная подпись была "выдана" API-серверу?! 1. Через клиента? Тогда клиент "знает" эту подпись? 2. Взаимодействием серверов? Но ведь утверждается, что мы избегаем их взаимодействия?! И еще: 3. Подпись вечная? Звучит плохо. 4. Если подпись не вечная, тогда как она "освежается"? Понимаю, что туплю, но не понимаю где...

[@smilesrg]

Илья, фон у тебя грустный и печальный )))

[@ОлексійМоренець]

gvt??? or JWT? %)

[@IlkinAlibayli]

Объяснение нравится, спасибо. Только бы английские слова выговаривать по английски...) Токéны, Áпи

[@ДмитроПрищепа-д3я]

Нет, конечно же, в tokens явно не на второй слог ударение.

[@sarbasov]

​@@ДмитроПрищепа-д3я 8:25 это автор видео говорит токе́н

[@404Negative]

обнаружен гуманитарий. уничтожить.

[@IlkinAlibayli]

@@404Negativeпшел ты)

[@ВиталийПугач-к8ю]

Реализовываю у себя, но вот задался вопросом, если при новом логине выписываем новый рефреш , а старый оставляем валидным то старый протухнет как только выйдет его время жизни, до этого им можно будет пользоваться вполне. Если мы делаем все старые рефреши не валидными (удаляем их например), то если юзер зашел со второго устройства - первое соответственно вылогиниться по истечению своего access_token. Как лучше поддерживать два устройства?

[@aditca5224]

ничего неясно, надо по шагам. Запросила аксес тоткен и рефреш токен первы раз - откуда они изначально берутся? потом сохранили их где, если не в куки? потом обращаемся к серверу ресруса и предъявляем ему что? аксес токен? Где таймер идет? на каком сервере? вроде что-то рассказали, но понимния стлько же, сколько т документации.

[@GMByteJavaTM]

15:01 - А как они станут автоматически невалидными, если сервер не знает что валидно, а что нет для конкретного пользователя, а знает только о том, что этот JWT был сгенерирован по определённому слову? Получается у него просто будут 2 валидных токена... не понял эту часть.

[@centwor1on167]

Мне тоже это непонятно. Вы поняли уже?

[@GMByteJavaTM]

@@centwor1on167 А, ну и ещё добавлю, не помню было ли это упомянуто в видео. Refresh токен обычно делают не JWT, а хранят именно на, допустим, сервере авторизаций, прямо где-то в базе, ну или на худой конец в памяти. Тут никаких противоречий нет, т.к. именно получение новых токенов в любом случае происходит где-то централизованно, а вот access-токены могут уже использоваться при обращении к разным серверам

[@КириллГаврилов-з9г]

а вот у меня такой вопрос по поводу JWT: Допустим мы получим ключ JWT и у нас будет иметься начальная часть(до шифрования) и конечная часть(шифрованная секретным словом). Разве невозможно подобрать секретное слово таким образом, это ведь как уравнение с одной неизвестной?

[@JavaScriptNinja]

Перебором можно. :)

[@КириллГаврилов-з9г]

@@JavaScriptNinja Ну перебором всё что угодно можно, вопрос в времени =)

[@Kreator321RG]

Спасибо!

[@mister-ace]

Ответьте пожалуйста, мне все ясно. Однако я не могу понять, возможно ли так авторизовать юзера в браузере? Через обычную форму , а там уже отправить ajax запрос на api?

[@ОлегЕвсеев-н9ъ]

ну а если только access token и deviceid?

[@VitalyP_Dev]

От меня постоянно какая-то недосказанность на моменте не покидает, где сказано что сервер аутентификации возвращает данные пользователя, и их закодированный хэш: сами данные что, тоже нельзя было закодировать? ну, отсылаешь клиенту этот хэш, клиент ничего не знает о данных, он отправляет их на апи, а он уже у себя раскодирует тем же секретным ключом.Ну должна же присутствовать логика аргументов : а то в начале по феншую всё шло, а в конце словно какой-то то джун доделал

[@JavaScriptNinja]

Зачем кодировать данные? Вы путаете подпись которая гарантирует неизменность данных с их шифрованием

[@SmiteVils]

JWT не зашло? Вижу давно видео нет

[@vladislav_pikiner]

на 1.75 то что нужно)

[@vitaliy.artyukh]

почему бы не держать авторизацию и API на одном сервере? тогда бы не понадобилось подтверждение кто есть кто.

[@JavaScriptNinja]

Потому что проекты разрастаются. Микросервисная архитектура и т.п. более того, у вас может быть сценарий что пользователь авторизуется на одном сервере, а потом (допустим) балансировщик нагрузки кидает его на другой

[@владимирсенцов-р1ю]

Ну можно. Но тогда придеться сессию делать распределенную. И прочие не очень удобные вещи.

[@kaflan-kun]

Оукей, а как в подобной системе делать полинги елси надо?

[@vrazovsky]

А кто-мешает сделать сервиc-метод "Ping" в который не надо передавать токен?

[@RagazzoKZ]

Не слышал про JWT. А где это используется? Как-то непонятно. Даже в русской википедии нет статьи об этом.

[@JavaScriptNinja]

en.wikipedia.org/wiki/JSON_Web_Token

[@daniilthegunner843]

А сейчас?))

[@gen7891]

Большая плотность информации. Вроде все должно быть понятно с первого раза, но кажется надо смотреть 2**n раз. Для объяснения протоколов юзайте диаграммы сиквенсов, не надо велосипедов.

[@redirex7770]

такЕн :DDDD

[@ivansidorov5]

Народ, я туплю что-то подскажите, вот отправили мы запрос FETCH через JS на сервер, сервер вернул нам куку, нашему AJAXу, эта кука установится в браузер?

[@orkhannabiev9192]

красиво

[@Ooshka]

Помогите: С клиента ловим токен, как узнать на node js (express) сколько осталось время жизни токена?

[@JavaScriptNinja]

Поле iat содержит время выдачи токена

[@Ooshka]

@@JavaScriptNinja спасибо :) главное что ответили)

[@haminidzinanusubalieva6622]

такены...

[@МаксимСеливанов-ь6н]

Дикция и подача конечно ппц, но в целом норм видосик, thx

[@smartliga8623]

Этот парень шарит. Похуй на дикцию. Его рисунки перекрывают все минусы.

[@MrGavr007]

да уж. пусть лучше статьи пишет

[@ii3246]

протухший токен, улыбнуло.))))

[@ДенисДенисов-п8о]

все отлично, но токЕн...))

[@MrReflection540]

За 15 минут так то можно кучу всего наворотить =\

[@ДилэймНиколсон]

JWT читается как "джот". Очень уж ваш "ДжейВиТи" слух режет) А ударение в слове тОкен на О :) А так клёвый урок, спасибо

[@musoverda5500]

Вас жестоко обманули насчет "читается" )) читается просто - "j - w - t" (см. букварь англ. языка)

[@ДилэймНиколсон]

С чего бы это?! en.wikipedia.org/wiki/JSON_Web_Token

[@musoverda5500]

не знаю как насчет Википедии ... Но вот нативный американец - kzbin.info/www/bejne/bZ_El5R-briXmrc А вот дамочка из официального Yuotube-канала фирмы Auth0 - kzbin.info/www/bejne/gF6cgmdsbtCsgMU - kzbin.info/www/bejne/joLRoJ2wg5l6ibs

[@musoverda5500]

вот еще ) - kzbin.info/www/bejne/nWOUpnuEfq6Yra8

[@ДилэймНиколсон]

Просто не все в теме, как правильно :) www.quora.com/Why-is-JSON-Web-Token-JWT-pronounced-jot В целом, можно произносить J W T как "Джей Даблъю Ти", но это немного коряво, ибо принято "джот". Но уж точно не "Джей Ви Ти"

[@rusnipyzda195]

x1.5

[@tee_zed]

за 15 минут можно что угодно сделать

[@denpol9956]

норм хромакей

[@perfectogamer3349]

ТокЕны, уши режет.

[@gagogoga794]

Очень полезно! Спасибо! Жаль что ты с Украины и сошел с ума, преподаешь на диалекте!

[@MrRomanvideo]

Весь мир идёт вперёд, одна раися вперду! А ты не задумывался, что ты разговариваешь как раз на диалекте украинского языка?

[@alex330k47]

Ну выкиньте уже нвконец то эти совковые шкафы

[@JavaScriptNinja]

Спасибо за заботу :) но родителям виднее чего они хотят

[@olegperov6395]

Ну ооочень секьюрно прям, с одним ключом. С таким же успехом можно просто чистым тестом отправлять. Есть реальные здоровые люди, которые так делают? Если подобрать ключ, то сможешь передавать на сервер любые данные и он будет считать их истинными.

[@JavaScriptNinja]

Ключ который хранится на сервере? Да, полно людей так делает, успехов в подборе ключа даже в 12 символов

[@eternal_wanderer_ru]

А rsa ключик подберешь?))

[@404Negative]

поняли, ребята. просто ключ подберите. и все деньги мира ваши.

[@Antonio-fm1sq]

Спасибо!

[@VladTsyb]

Спасибо!