Добрый день, у меня 2 вопроса: 1) как лучше хранить refresh_token в mssql базе (В таблице юзера? И как хранить его дату истекания? То есть это должен быть какой то Json поле в таблице user`a и при получении access_token обновлять это поле всегда? Или можно как то подругому?)? 2) как на клиенте узнать что просрочен access_token (нужно ли для этого делать доп запросы? Или просто если при запросе пришел 401 ответ, сделать запрос на сервер аунтификации и авторизации и получить новый?) Заранее спасибо, застрял на этих вопросах, хочу сделать как лучше.
Прошу прощения за тупость, но на 6:58 - Каким образом секретная подпись была "выдана" API-серверу?! 1. Через клиента? Тогда клиент "знает" эту подпись? 2. Взаимодействием серверов? Но ведь утверждается, что мы избегаем их взаимодействия?! И еще: 3. Подпись вечная? Звучит плохо. 4. Если подпись не вечная, тогда как она "освежается"? Понимаю, что туплю, но не понимаю где...
Ответьте пожалуйста, мне все ясно. Однако я не могу понять, возможно ли так авторизовать юзера в браузере? Через обычную форму , а там уже отправить ajax запрос на api?
Если его, по вашим словам, нельзя передавать, то как вы собираетесь его использовать? Либо передаете в Authentication хедере, либо как HTTP-only куки. Но передать придется в любом случае, без этого сервак вас не узнает
@@ДмитроПрищепа-д3я Скажи JWT существует потому что AJAX запросы не шифруються как HTTP? И bearer токен имеет двойное назначение как токен авторизации и токен для подписей данных?
@@ЕвгенийБорисов-е1ч JWT(как и другие авторизационные токены) существует потому, что в REST приложениях не хранится состояние пользователей, поэтому и все данные для аутентификации нужно передавать вместе с запросами(не совсем полная история, конечно, в целом токенная атуентификация существует потому, что очень часто она удобнее, чем сессии). Кстати, HTTP не шифруется вообще, это просто протокол прикладного уровня над TCP. Шифруется уже расширенная его версия - HTTPS. К токенам это отношения не имеет. Bearer - тип схемы аутентификации в Authorization заголовке запроса, который означает, что после него идет такой токен, что подходит для доступа к ресурсам, защищенным по OAuth 2.0. Упрощенно говоря это значит, что такого токена полностью достаточно для получения наиболее полного доступа к ресурсу(наличие любого криптографического ключа у носителя токена не проверяется). Более подробно читать, собственно, спецификацию, а конкретно RFC 6750(datatracker.ietf.org/doc/html/rfc6750). Таким образом видно, что JWT полностью соответствует этой спецификации. Назначение Bearer токена - исключительно авторизация, по крайней мере в изначальном его смысле. Сами данные при этом могут, в зависимости от апи, передаваться в любом желаемом виде, хоть сырыми как query-параметры или в теле, хоть асимметрично шифрованными/как-то подписанными. Токен(и конкретно JWT тоже) к ним отношения не имеет, лишь к аутентификации пользователя, сделавшего запрос.
Реализовываю у себя, но вот задался вопросом, если при новом логине выписываем новый рефреш , а старый оставляем валидным то старый протухнет как только выйдет его время жизни, до этого им можно будет пользоваться вполне. Если мы делаем все старые рефреши не валидными (удаляем их например), то если юзер зашел со второго устройства - первое соответственно вылогиниться по истечению своего access_token. Как лучше поддерживать два устройства?
Похоже, что просто количество необходимой коммуникации снизилось существенно. С JWT серверам авторизации и апи нужно общаться не каждый запрос пользователя к апи, а только в момент смены пары токенов.
@@georgemanlove7411 разве это обязательно должно убивать предыдущие пары? А как тогда держать авторизацию на нескольких устройствах? Ведь логин в одном будет убивать другой.
интересно то что если хакер успел поменять логин и пароль пользователя, до истечения скрока токена, то и перелогинится пользователю будет сложнее и то если єта функциональность заимплеменчина в виде сброса пароля и т.д.
Похоже нужно хранить все рефреш токены в БД и не удалять их, а при колизии нужно заблокировать все рефреш токены пользователя. При этом пользователю на всех устройствах и злоумышлинику нужно будет перелогинится.
Но ведь у хакера останется не валидный рефреш токен. Он как минимум сможет постоянно пытаться его рефрешить что будет всегда сбивать все рефреш токены для реального пользователя. Да и вообще, для этого и красть то не нужно ничего. Зная userId пользователя можно генерить не валидные токены, отслылать их на ендпоинт для рефреша и тем самым сбивать все токены реально пользователя. Вот такое западло получается можно делать. Как-то не понятно с этим моментом.
@@valeron_1337 1) Юзер логинится. 2) Мы создаем аксес токен и рефреш токен 3) сохраняем рефреш токен (токен, юзер айди, флаг использования, и время действия) 4) возвращаем токены 1) происходит рефреш запрос от юзера. 2) проверяем наличие токена в бд, проверяем что токен не использовался, проверяем что токен не протух. Если токен валидный то заменяем флаг на использован и выдаём новую пару токенов. Если токен не найден в бд или он просрочен то возвращаем 401. Если токен был использован, то скорее всего он был скомпрометирован и мы удаляем все рефреш токены (или заносим в бан, к примеру) И теперь единственный способ получить рефреш токен это авторизация. Так как мы удалили токены то колизия не произойдет повторно.
@@dmytro_bro Большое спасибо за разъяснение. Звучит надежно. Поделитесь пожалуйста ресурсом откуда почерпнули данное решение, если не сами до него дошли. Я просто сейчас посмотрел третий урок (Сервер) и исходя из него, описанный сценарий вполне возможен. То есть, получается как вы и написали в своем первом комментарии, сервер будет трактовать перелогиненого пользователя и хакера как две сессии на разных устройствах.
15:01 - А как они станут автоматически невалидными, если сервер не знает что валидно, а что нет для конкретного пользователя, а знает только о том, что этот JWT был сгенерирован по определённому слову? Получается у него просто будут 2 валидных токена... не понял эту часть.
@@centwor1on167 А, ну и ещё добавлю, не помню было ли это упомянуто в видео. Refresh токен обычно делают не JWT, а хранят именно на, допустим, сервере авторизаций, прямо где-то в базе, ну или на худой конец в памяти. Тут никаких противоречий нет, т.к. именно получение новых токенов в любом случае происходит где-то централизованно, а вот access-токены могут уже использоваться при обращении к разным серверам
а вот у меня такой вопрос по поводу JWT: Допустим мы получим ключ JWT и у нас будет иметься начальная часть(до шифрования) и конечная часть(шифрованная секретным словом). Разве невозможно подобрать секретное слово таким образом, это ведь как уравнение с одной неизвестной?
ничего неясно, надо по шагам. Запросила аксес тоткен и рефреш токен первы раз - откуда они изначально берутся? потом сохранили их где, если не в куки? потом обращаемся к серверу ресруса и предъявляем ему что? аксес токен? Где таймер идет? на каком сервере? вроде что-то рассказали, но понимния стлько же, сколько т документации.
От меня постоянно какая-то недосказанность на моменте не покидает, где сказано что сервер аутентификации возвращает данные пользователя, и их закодированный хэш: сами данные что, тоже нельзя было закодировать? ну, отсылаешь клиенту этот хэш, клиент ничего не знает о данных, он отправляет их на апи, а он уже у себя раскодирует тем же секретным ключом.Ну должна же присутствовать логика аргументов : а то в начале по феншую всё шло, а в конце словно какой-то то джун доделал
Потому что проекты разрастаются. Микросервисная архитектура и т.п. более того, у вас может быть сценарий что пользователь авторизуется на одном сервере, а потом (допустим) балансировщик нагрузки кидает его на другой
Народ, я туплю что-то подскажите, вот отправили мы запрос FETCH через JS на сервер, сервер вернул нам куку, нашему AJAXу, эта кука установится в браузер?
Большая плотность информации. Вроде все должно быть понятно с первого раза, но кажется надо смотреть 2**n раз. Для объяснения протоколов юзайте диаграммы сиквенсов, не надо велосипедов.
не знаю как насчет Википедии ... Но вот нативный американец - th-cam.com/video/7nafaH9SddU/w-d-xo.html А вот дамочка из официального Yuotube-канала фирмы Auth0 - th-cam.com/video/J-9Q469kyJc/w-d-xo.html - th-cam.com/video/XQnojzN4GSY/w-d-xo.html
Просто не все в теме, как правильно :) www.quora.com/Why-is-JSON-Web-Token-JWT-pronounced-jot В целом, можно произносить J W T как "Джей Даблъю Ти", но это немного коряво, ибо принято "джот". Но уж точно не "Джей Ви Ти"
Ну ооочень секьюрно прям, с одним ключом. С таким же успехом можно просто чистым тестом отправлять. Есть реальные здоровые люди, которые так делают? Если подобрать ключ, то сможешь передавать на сервер любые данные и он будет считать их истинными.
Круто объяснено! На пальцах, с картинками, все ясно )))
Большое спасибо!! Я часа 2 читал что да как, не мог понять, а в видео все сразу стало ясно. Респект
Классный урок. Вот бы все так объясняли)
Илья умеет объяснять сложные темы, простыми словами!
СПАСИБО ОГРОМНОЕ за разъяснение 🤝
Большое спасибо!! Отличное объяснение с наглядными схеами
Шикарно объяснил! Подписываюсь
ЭТО ШЕДЕВР
на 1.5 отлично
спасибо👍
@@МаксЕрмышев а мне на 1.25х комфортно было
мне на 2
@@CrazyMongol123 мне 0.5 норм
Спасибо за видео!
Досмотрел до конца
объясняете доходчиво! Советую смотреть на х2, очень тягучая манера говорить, а на ускоренном всё супер)
Спасибо, очень нужно и интересно
очень понятно! спасибо за труд!
Cпасибо ! Очень понятно!
Душевно объяснил, лайк и подписка сразу же таким пацанам
Спасибо за фильм, привет из Польши ;)
Вот и пригодилось) Спасибо!
Блэт, годный видос👍
Спасибо, очень классно все разъяснено
Все шикарно объяснено, единственный момент, причем тут такены
Неплохо объяснено, плюс минус все понятно
Супер! Спасибо большое
Спасибо за видео
14:46 а с чего это токены которые были у хакера станут не корректными? Ведь речь идет что - при условии что не используется хранилище токенов.
Тот же вопрос, автор сам сказал что нет механизма отзыва токенов
супер, нет слов
Добрый день, у меня 2 вопроса:
1) как лучше хранить refresh_token в mssql базе (В таблице юзера? И как хранить его дату истекания? То есть это должен быть какой то Json поле в таблице user`a и при получении access_token обновлять это поле всегда? Или можно как то подругому?)?
2) как на клиенте узнать что просрочен access_token (нужно ли для этого делать доп запросы? Или просто если при запросе пришел 401 ответ, сделать запрос на сервер аунтификации и авторизации и получить новый?)
Заранее спасибо, застрял на этих вопросах, хочу сделать как лучше.
2 отправь на клиент дополнительный заголовок, что срок годности токена истек
Спасибо!
Спасибо большое!
Прошу прощения за тупость, но на 6:58 - Каким образом секретная подпись была "выдана" API-серверу?!
1. Через клиента? Тогда клиент "знает" эту подпись?
2. Взаимодействием серверов? Но ведь утверждается, что мы избегаем их взаимодействия?!
И еще:
3. Подпись вечная? Звучит плохо.
4. Если подпись не вечная, тогда как она "освежается"?
Понимаю, что туплю, но не понимаю где...
Ответьте пожалуйста, мне все ясно. Однако я не могу понять, возможно ли так авторизовать юзера в браузере? Через обычную форму , а там уже отправить ajax запрос на api?
Спасибо
Thank you!
спасибо!
Обьясните нафига токен передавать в Bearer заголовке тоесть палить токен? Его же нельзя передовать?
Если его, по вашим словам, нельзя передавать, то как вы собираетесь его использовать?
Либо передаете в Authentication хедере, либо как HTTP-only куки. Но передать придется в любом случае, без этого сервак вас не узнает
@@ДмитроПрищепа-д3я Скажи JWT существует потому что AJAX запросы не шифруються как HTTP? И bearer токен имеет двойное назначение как токен авторизации и токен для подписей данных?
@@ЕвгенийБорисов-е1ч JWT(как и другие авторизационные токены) существует потому, что в REST приложениях не хранится состояние пользователей, поэтому и все данные для аутентификации нужно передавать вместе с запросами(не совсем полная история, конечно, в целом токенная атуентификация существует потому, что очень часто она удобнее, чем сессии).
Кстати, HTTP не шифруется вообще, это просто протокол прикладного уровня над TCP. Шифруется уже расширенная его версия - HTTPS. К токенам это отношения не имеет.
Bearer - тип схемы аутентификации в Authorization заголовке запроса, который означает, что после него идет такой токен, что подходит для доступа к ресурсам, защищенным по OAuth 2.0. Упрощенно говоря это значит, что такого токена полностью достаточно для получения наиболее полного доступа к ресурсу(наличие любого криптографического ключа у носителя токена не проверяется). Более подробно читать, собственно, спецификацию, а конкретно RFC 6750(datatracker.ietf.org/doc/html/rfc6750). Таким образом видно, что JWT полностью соответствует этой спецификации.
Назначение Bearer токена - исключительно авторизация, по крайней мере в изначальном его смысле. Сами данные при этом могут, в зависимости от апи, передаваться в любом желаемом виде, хоть сырыми как query-параметры или в теле, хоть асимметрично шифрованными/как-то подписанными. Токен(и конкретно JWT тоже) к ним отношения не имеет, лишь к аутентификации пользователя, сделавшего запрос.
@@ДмитроПрищепа-д3я Ну вот я и слышал постоянно про JWT авторизацию и Bearer токен и у меня все смешалось и я запутался ну теперь чуть яснее
Реализовываю у себя, но вот задался вопросом, если при новом логине выписываем новый рефреш , а старый оставляем валидным то старый протухнет как только выйдет его время жизни, до этого им можно будет пользоваться вполне. Если мы делаем все старые рефреши не валидными (удаляем их например), то если юзер зашел со второго устройства - первое соответственно вылогиниться по истечению своего access_token. Как лучше поддерживать два устройства?
Respect!!!
Объяснение нравится, спасибо.
Только бы английские слова выговаривать по английски...)
Токéны, Áпи
Нет, конечно же, в tokens явно не на второй слог ударение.
@@ДмитроПрищепа-д3я 8:25 это автор видео говорит токе́н
обнаружен гуманитарий. уничтожить.
@@404Negativeпшел ты)
как злоумышленник сможет украсть access_token если мы к примеру используем HTTPS соединения?
спасибо, классно.
Что-то не очень понятен финт на 7:00. Получается они все равно общаются между собой, раз делят ключ? Но ведь мы хотели избавиться от этой связи?
Похоже, что просто количество необходимой коммуникации снизилось существенно. С JWT серверам авторизации и апи нужно общаться не каждый запрос пользователя к апи, а только в момент смены пары токенов.
каким образм refresh токен хакера, после перелогина настоящего пользователя станет невалидным??
Пользователю будет выдана новая пара access-refresh токенов
@@georgemanlove7411 разве это обязательно должно убивать предыдущие пары? А как тогда держать авторизацию на нескольких устройствах? Ведь логин в одном будет убивать другой.
интересно то что если хакер успел поменять логин и пароль пользователя, до истечения скрока токена, то и перелогинится пользователю будет сложнее и то если єта функциональность заимплеменчина в виде сброса пароля и т.д.
@@user-varmat Вот я тоже об этом подумал. А если например еще и поменял e-mail или телефон.
gvt??? or JWT? %)
14:20 Каким образом рефреш токен который заполучил хакер становится не валидным? А что если честный пользователь логинится с двух устройств?
Похоже нужно хранить все рефреш токены в БД и не удалять их, а при колизии нужно заблокировать все рефреш токены пользователя. При этом пользователю на всех устройствах и злоумышлинику нужно будет перелогинится.
Тоже не понял. Он по логике с длинной жизнью, когда протухает акссес, рефреш генерит заново пару.
Но ведь у хакера останется не валидный рефреш токен. Он как минимум сможет постоянно пытаться его рефрешить что будет всегда сбивать все рефреш токены для реального пользователя. Да и вообще, для этого и красть то не нужно ничего. Зная userId пользователя можно генерить не валидные токены, отслылать их на ендпоинт для рефреша и тем самым сбивать все токены реально пользователя. Вот такое западло получается можно делать.
Как-то не понятно с этим моментом.
@@valeron_1337 1) Юзер логинится.
2) Мы создаем аксес токен и рефреш токен
3) сохраняем рефреш токен (токен, юзер айди, флаг использования, и время действия)
4) возвращаем токены
1) происходит рефреш запрос от юзера.
2) проверяем наличие токена в бд, проверяем что токен не использовался, проверяем что токен не протух.
Если токен валидный то заменяем флаг на использован и выдаём новую пару токенов.
Если токен не найден в бд или он просрочен то возвращаем 401.
Если токен был использован, то скорее всего он был скомпрометирован и мы удаляем все рефреш токены (или заносим в бан, к примеру) И теперь единственный способ получить рефреш токен это авторизация.
Так как мы удалили токены то колизия не произойдет повторно.
@@dmytro_bro Большое спасибо за разъяснение. Звучит надежно. Поделитесь пожалуйста ресурсом откуда почерпнули данное решение, если не сами до него дошли.
Я просто сейчас посмотрел третий урок (Сервер) и исходя из него, описанный сценарий вполне возможен. То есть, получается как вы и написали в своем первом комментарии, сервер будет трактовать перелогиненого пользователя и хакера как две сессии на разных устройствах.
Не путайте Авторизацию и Аутентификацию!
не будем!
@@aleksandrkravtsov8727 :)
Вот именно, в видео рассказывается про аутентификацию. А еще небольшая каша с пониманием криптографии с открытым ключом
15:01 - А как они станут автоматически невалидными, если сервер не знает что валидно, а что нет для конкретного пользователя, а знает только о том, что этот JWT был сгенерирован по определённому слову? Получается у него просто будут 2 валидных токена... не понял эту часть.
Мне тоже это непонятно. Вы поняли уже?
@@centwor1on167 А, ну и ещё добавлю, не помню было ли это упомянуто в видео. Refresh токен обычно делают не JWT, а хранят именно на, допустим, сервере авторизаций, прямо где-то в базе, ну или на худой конец в памяти. Тут никаких противоречий нет, т.к. именно получение новых токенов в любом случае происходит где-то централизованно, а вот access-токены могут уже использоваться при обращении к разным серверам
Не слышал про JWT. А где это используется? Как-то непонятно. Даже в русской википедии нет статьи об этом.
en.wikipedia.org/wiki/JSON_Web_Token
А сейчас?))
а вот у меня такой вопрос по поводу JWT: Допустим мы получим ключ JWT и у нас будет иметься начальная часть(до шифрования) и конечная часть(шифрованная секретным словом). Разве невозможно подобрать секретное слово таким образом, это ведь как уравнение с одной неизвестной?
Перебором можно. :)
@@JavaScriptNinja Ну перебором всё что угодно можно, вопрос в времени =)
Это была песня из Безконечного лета в начале?
ничего неясно, надо по шагам. Запросила аксес тоткен и рефреш токен первы раз - откуда они изначально берутся? потом сохранили их где, если не в куки? потом обращаемся к серверу ресруса и предъявляем ему что? аксес токен? Где таймер идет? на каком сервере? вроде что-то рассказали, но понимния стлько же, сколько т документации.
на 1.75 то что нужно)
не хватило информации что значит проверить корректность этих данных на основании подписи 7:40
ну а если только access token и deviceid?
красиво
Илья, фон у тебя грустный и печальный )))
От меня постоянно какая-то недосказанность на моменте не покидает, где сказано что сервер аутентификации возвращает данные пользователя, и их закодированный хэш: сами данные что, тоже нельзя было закодировать? ну, отсылаешь клиенту этот хэш, клиент ничего не знает о данных, он отправляет их на апи, а он уже у себя раскодирует тем же секретным ключом.Ну должна же присутствовать логика аргументов : а то в начале по феншую всё шло, а в конце словно какой-то то джун доделал
Зачем кодировать данные? Вы путаете подпись которая гарантирует неизменность данных с их шифрованием
JWT не зашло? Вижу давно видео нет
такЕн :DDDD
Оукей, а как в подобной системе делать полинги елси надо?
А кто-мешает сделать сервиc-метод "Ping" в который не надо передавать токен?
почему бы не держать авторизацию и API на одном сервере? тогда бы не понадобилось подтверждение кто есть кто.
Потому что проекты разрастаются. Микросервисная архитектура и т.п. более того, у вас может быть сценарий что пользователь авторизуется на одном сервере, а потом (допустим) балансировщик нагрузки кидает его на другой
Ну можно. Но тогда придеться сессию делать распределенную. И прочие не очень удобные вещи.
Народ, я туплю что-то подскажите, вот отправили мы запрос FETCH через JS на сервер, сервер вернул нам куку, нашему AJAXу, эта кука установится в браузер?
Помогите:
С клиента ловим токен, как узнать на node js (express) сколько осталось время жизни токена?
Поле iat содержит время выдачи токена
@@JavaScriptNinja спасибо :) главное что ответили)
Большая плотность информации. Вроде все должно быть понятно с первого раза, но кажется надо смотреть 2**n раз. Для объяснения протоколов юзайте диаграммы сиквенсов, не надо велосипедов.
протухший токен, улыбнуло.))))
все отлично, но токЕн...))
Дикция и подача конечно ппц, но в целом норм видосик, thx
Этот парень шарит. Похуй на дикцию. Его рисунки перекрывают все минусы.
да уж. пусть лучше статьи пишет
такены...
JWT читается как "джот". Очень уж ваш "ДжейВиТи" слух режет)
А ударение в слове тОкен на О :)
А так клёвый урок, спасибо
Вас жестоко обманули насчет "читается" ))
читается просто - "j - w - t" (см. букварь англ. языка)
С чего бы это?!
en.wikipedia.org/wiki/JSON_Web_Token
не знаю как насчет Википедии ...
Но вот нативный американец -
th-cam.com/video/7nafaH9SddU/w-d-xo.html
А вот дамочка из официального Yuotube-канала фирмы Auth0
- th-cam.com/video/J-9Q469kyJc/w-d-xo.html
- th-cam.com/video/XQnojzN4GSY/w-d-xo.html
вот еще )
- th-cam.com/video/g21uHNIIewM/w-d-xo.html
Просто не все в теме, как правильно :)
www.quora.com/Why-is-JSON-Web-Token-JWT-pronounced-jot
В целом, можно произносить J W T как "Джей Даблъю Ти", но это немного коряво, ибо принято "джот". Но уж точно не "Джей Ви Ти"
За 15 минут так то можно кучу всего наворотить =\
x1.5
за 15 минут можно что угодно сделать
норм хромакей
ТокЕны, уши режет.
Очень полезно! Спасибо! Жаль что ты с Украины и сошел с ума, преподаешь на диалекте!
Весь мир идёт вперёд, одна раися вперду! А ты не задумывался, что ты разговариваешь как раз на диалекте украинского языка?
Ну выкиньте уже нвконец то эти совковые шкафы
Спасибо за заботу :) но родителям виднее чего они хотят
Ну ооочень секьюрно прям, с одним ключом. С таким же успехом можно просто чистым тестом отправлять. Есть реальные здоровые люди, которые так делают? Если подобрать ключ, то сможешь передавать на сервер любые данные и он будет считать их истинными.
Ключ который хранится на сервере? Да, полно людей так делает, успехов в подборе ключа даже в 12 символов
А rsa ключик подберешь?))
поняли, ребята. просто ключ подберите. и все деньги мира ваши.
Спасибо!
Спасибо!