JWT токены: формирование payload
HTML-код
- Опубликовано: 2 окт 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
можешь сделать видео по сетям про NAT tcp/ip про модель osi и все такое и ещё что-нибудь низкоуровневое
к jwt есть один офигенный вопрос. Как разлогинеть пользователя? все методы решения решаются по сути теми же методами что и сессия. Тогда непонятно нафига нужет этот jwt.
JWT позволяет авторизировать пользователя не трогая базу. А данные сессии обычно приходится из этой самой базы на каждом запросе вытаскивать. Плюс токен может быть выдан одним сервисом, а потребляться кучей других. Еще и на фронтенде у тебя в токене сразу вся нобхзодимая информация (доступы пользователя) для корректного отображения UI есть.
JWT обычно живут максимум 5-10 минут, и изначально не предназначены для моментального разрыва сессии.
Как вариант - хранить в базе время разлогина и при авторизации проверки соответствующие добавлять
@@Slavec5 не очень понял. Вот мне надо разлогинить пользователя со всех устройств моментально. Как это сдлеать? Если я поменяю ключ шифрования то я разлогиню всех.
@@PurpleDaemon_ то есть если я хочу резко разлогинить юзера на всех устройствах, мне придется убить его рефреш токен? И при этом 5-10 минут с других устройств еще можно будет зайти?
@@kl45gp да. Можно придумать костыли, но тогда от jwt больше проблем, чем пользы получится. Он просто не задуман для таких случаев.
Не совсем понятно про какие публичные ключи говорится ближе к концу видео. Создается ощущение, что имеется ввиду публичный ключ проверки подписи. Но он никак не может быть в самом токене, иначе его запросто подменят и переподпишут токен заново.
Я тоже понять не могу. Вырвал из хабры. Еще может использоваться другой алгоритм RS256 - в отличие от предыдущего, он является ассиметричным и создает два ключа: публичный и приватный. С помощью приватного ключа создается подпись, а с помощью публичного только лишь проверяется подлинность подписи, поэтому нам не нужно беспокоиться о его безопасности.
Тут говорится не про ключи с помощью которых подписывают, а про ключи словаря. Публичные значит объявленные в стандарте(спецификации, RFC). Т.е их должны понимать (зачем вы его использовали) все разработчики которые впервые видят ваш токен.
А не публичные это только ваши ключи, назначение которых другие разработчики не обязаны понимать.
@@diatm1506 я и говорил про ассинхронные алгоритмы вроде rs256. Ты всё-равно не можешь хранить публичный ключ в токене, так как его подменят на новый публичный ключ и подпишу новым приватный ключём, а ты об этом не узнаешь, так как подпись то валидная. Поэтому публичный ключ должен выдаваться апишкой со строго зафисксированым URL, которая желательно ещё и автоматически обновляет выдаваемые ключи раз в n дней. Это вроде jwks называется. Ну или просто быть зафисксированым где нибудь в переменных окружения, если ротировать часто не собираетесь.
@@unnamed-xx3kr спасибо за пояснение. Теперь всё ясно.
@@unnamed-xx3kr это вообще на мой взгляд общепринятые правила хорошего тона в коммерческой разработке на открытых решениях, и встречается далеко не только в rfc
спасибо за вклад в развитие индустрии
Спасибо за видео. Коммент в поддержку!
Хорошая тема, Соер. Думаю стоит ещё рассказать о том, как их безопасно хранить на фронте, например. А то слишком много людей, видосов и т.д где показывают сохранение в localStorage, что вообще не безопасно.
В шифрованных куки, как ещё. Странный вопрос.
Вода водой.... лучше бы рассказали кто формирует подпись, на основании чего, по каким ключам, как проверяется?
OpenID Connect, OAuth 2.0 и JWT в чем различия?
А какая оптимальная длина токена? А то некоторые кладут туда кучу информации и токен получается огромным.
Непонятен смысл использования неподписанных токенов - для того чтобы где то в процессе передачи можно было содержимое модифицировать?
Только хотел разобратся в теме и тут соер оперативно мне все объяснил. Спасибо.
джот токены?
Соер а как ты относишься к rxjs? (reative x) стоит или нет использовать, является ли это функциональным программированием, как такое дебажить? Хотелось бы твоё мнение
Можешь ещё сделать видео про jwe, мало информации об этом в интернетах
не понимаю, если jwt токен может прочитать любой, как же происходит авторизация. Что насчет перехвата чужих токенов? Получается мы можем получить данные которые нам нельзя смотреть
В токене не передают уязвимую информацию. Пускай читают токен, это ничего не даст.
Получат айди юзера, имя или то, что ты туда положил как полезную нагрузку.
Токен позволяет проверить тебя как пользователя который был аутентифицирован и получил токен закодированый токен (не зашифрованный).
Когда ты попытаешься получить доступ к странице которая пускает только админов, получишь отказ, так как полезная нагрузка, которую ты предоставил для генерации токена имеет роль юзер, а нужен админ.
Но, допустим ты решил поменять роль на админ в токене, раскодировал его и поменял роль на админ.
Что бы раскодировать токен, секрет не нужен.
Токен поменялся и теперь не совпадает с тем который был тебе выдан.
Когда ты опять постучишься с новой ролью, твой токен проверят с секретным ключем и подписи совпадать не будут.
Сгенерируют новую подпись с использованием ключа и если она не совпадает, получишь отказ.
Тут нужно понять то, что при изменении 1 едеиницы, токен полностью меняется.
Злодей изменивший роль, не ииеет доступа к секрету, а соответственно подпись меняется в токене на клиенте с новой ролью.
А когда проверяем токен, посредством генерации подписи с секретом.
Та подпись которая сгенерирована на сервере не будет соответствовать той, которая пришла от юзера, так как изменял ты ее не клиенте без секрета.
@@v.demchenko спасибо, очень хорошо расписал, я бы еще в телеграме обсудил некоторые моменты
Евгений,а с какой целью вы передаете данные об ордерах используя jwt?
Актуальная на сегодняшний день тема, спасибо, полезно
спасибо! Очень информативно!
Возможно не SOER а Sawyer
Отличное видео!
О, спсб за видос)) Делай вещи.
Ждем след видео! Спасибо!
Только по работе требоваться начало, а тут такое классное объяснение, спасибо❤️
даешь следующее видео)
Спасибо))
Спасибо!
Ничего непонятно без примера.
Лекция крутая, но мне кажется автор путает понятия аутентификации и авторизации
Кажется говорят: когда кажется - креститься надо)