Что такое JWT и как его создать

[@Jay82rus]

Даешь OAuth и OpenID для народа!

[@ListenIT_channel]

Понял, беру на заметку 👌

[@bennails3447]

@@ListenIT_channel Очень было бы интересно посмотреть реализацию и API запросы при использовании этих технологий🤩😍

[@ListenIT_channel]

А вот и OAuth и OpenID в новом видео kzbin.info/www/bejne/jZDJl6qvmsucbqM

[@valerysilakov3498]

Спасибо за видео! Интересно и констурктивно подана информация. Теперь и правда хочется послушать про OAuth и OpenID 😊

[@ListenIT_channel]

А вот и OAuth и OpenID подъехали kzbin.info/www/bejne/jZDJl6qvmsucbqM

[@nikitabbrv5947]

после этого видео необходимо сравнение session-cookis vs jwt)

[@kidsShow1998]

спасибо большое, было довольно понятно и ясно

[@bublck-gt1lo]

Чувак спасибо за твои видосы !

[@ListenIT_channel]

Спасибо, что смотришь! И спасибо авторам статей, конечно.

[@VadimBryksin]

Несколько нюансов: 1) если напихать слишком много данных в клэйм токена, то токен может превысить лимит хэдера в HTTP запросе, так что размер JWT все-таки конечный, лично сталкивались и приходилось лимитировать... 2) по рефреш токену - тема не раскрыта, кто должен мониторить за экспаирлися токен или нет? * если клиент, то это должен быть какой-то крон на клиентской стороне (допустим раз в минуту) который по тригеру будет рефрешить токен, но тогда нужно мониторить активность юзера и отрубать ежеминутный крон как только юзер стал не активным. * или клиент всегда делает запрос с токеном что у него сейчас есть и в ответ получает 401 потому что токен за экспаирился? и только в этом случае клиент рефрешит аксеес токен? а что с запросом который уже за фэилился? это нужно тогда иметь какой-то локальный стак на клиенте, куда складывать все отправленные запросы чтоб в случае с 401, можно было за рефрешить токен и пере повторить запрос из сохраненного стака? + менеджить стак чистя его при успешых запросах * может еще какие-то варианты есть? Как правильно то?

[@tami-he4mm]

Я думаю не обязательно мониторить, к примеру возьмем такой пример: у тебя истек access_token, но не refresh_token, при следующем запросе (возьмем endpoint: /home) передавая токены, сервер может вернуть 401 Unauthorized в response может быть тип ошибки к примеру tokes is invalid или token is expired, ты в клиентской части берешь и делаешь запрос на endpoint (к примеру /refresh) которые генерирует новые токены передав refresh token в body request-a, и получаешь новые токены, если там также ошибка это означает что refreshs_token истек тоже то есть в конечном итоге мы получаем что нам не нужно мониторить каждую а минуту, а просто ждать 401 Response от сервера

[@VadimBryksin]

@@tami-he4mm полагаю вы не очень внимательно прочитали мой оригинальный пост? То что вы описываете я так же описал как 2я опция, которая так же имеет свои проблемы и не удобства

[@dreksenthebest9738]

@@VadimBryksin во второй опции запрос не фейлится, так как рефреш верный, и к тому же выдается новый аксесс токен (я так думаю)

[@VadimBryksin]

@@dreksenthebest9738 это вы так думаете, но рефреш токен не посылается при каждом запросе, а используется только когда делается рефреш, так что при экспаире аксес токина сервер не знает валидный у тебя ревреш токен или нет. короче у нас в проде мы реализовали первый вариант, 2й со стаком слишком муторный. но как по правилам надо ОП в видео не рассказал.

[@fu7ur3gh057]

канал заебись💥 очень хотел бы услышать про OAuth, и про тему разницы хеширования и кодирования

[@ListenIT_channel]

Ок, будет 👌

[@ListenIT_channel]

А вот и OAuth и OpenID подъехали kzbin.info/www/bejne/jZDJl6qvmsucbqM

[@linkerloader47]

Даёшь OpenAPI 3.0 !☝️

[@limeniye]

Тема JWT и микросервисов не бьіла затронута, как по-моему очень важная тема

[@andrewkotov3234]

Это да, так как это база!

[@vitaliySobakinson]

Как всегда супер)

[@Dragonboh1]

ну если так терминологию использовать то шифрование делаетса методом кодирования, что означает что данние в JWT зашифрованние

[@spadar1602]

В чем смысл refresh_token если мы его также с клиента передаем на сервер как и access_token? Вот если мы refresh запишем в куку как httponly и secure, то смысл появляется, так как сервер сам с ним взаисодействует и это безопасно потому что с клиента нет к нему доступа.

[@nurlytan_berikbol]

Refresh так и передается же в куках с httponly secure, а так да реально нету смысла передавать если как access

[@robert33232]

Спасибо!

[@Dragonboh1]

Я щапутался JWT незашифрован, но сервер расскодирует ключем. Так значит сам JWT зашифрован? или имелось ввиду что данние которие передаютса вместе с JWT не зашифрованние? и Какой смисл в JWT тогда если данние не шефруютса. Я могу же перехватить токен и ево использовать с другим телом запроса. Както не особо понятно

[@dariavadimovna8611]

спасибо)

[@nickfox5394]

Можно ещё записать видео))))

[@Kirill.Bogdanovich]

благодарю

[@MrShevrin]

про рефрештокен я запутался)

[@ListenIT_channel]

Ну там ничего сложного: делаем один токен для доступа (access), который мало живёт, и делаем долгоживущий refresh-токен. Пользователь ходит в приложение с access-токеном, пока тот не просрочится, а как просрочится, то кидает в приложение refresh-токен, чтобы перевыпустить access-токен.

[@irker8220]

Что за звук, который играет в заставке в первую секунду? Очень знакомый, но не могу понять из какой игры ... Starcraft ?

[@ListenIT_channel]

Подсказка: в этом звуке участвуют слова "палатка" и "помощь"...)

[@irker8220]

@@ListenIT_channel Все, спасибо!)) Сразу понял) Герои 3

[@ЕвгенийОльхин-ы4о]

Интересно

[@АнастасияХохлова-ю4к]

Хотим перевод статьи про кодирование и шифрование !

[@wce-tube]

- Ну, слушайте статью из мира IT (LISTEN IT) ...5 минут спустя... - Ну, посмотрите на экран 😅

[@ListenIT_channel]

Всё-таки не очень будет классно звучать, если в статье озвучивать токен)

[@wce-tube]

Большой интерес в комментариях - проснулся

[@chickeneffect]

тестировщики здесь 🤙🏻🤙🏻

[@markerok3411]

Если по итогу данные в JWT кодируются с помощью секретного ключа, который есть только на сервере и у пользователя, то почему по нему не безопасно передавать данные паспорта?

[@saitama-ll8jr]

Если я правильно понял, header и payload шифруется c помощью base64. Т.е. любой, кто получит токен, может просто прогнать их через декодер и получить исходные данные. Именно шифруется только signature, но сама строка signature является теми самыми закодированными header и payload, соединёнными точкой. API при каждом запросе будет сравнивать в пришедшем JWT часть header.payload и расшифрованную с помощью секретного ключа signature. Если они равны, то проверка пройдёт успешно. Надеюсь, что понятно объяснил.

[@good_job_naum]

1. Секретный ключ есть только у сервера авторизации и клиентского сервера. У пользователя нет секретного ключа. 2. Хедер и пэйлоад не шифруются, они кодируются base64. Это значит, что с помощью декодера эти данные можно раскодировать. Что, собственно, и делает клиентский сервер: 1) Декодирует хедер и пэйлоад и получает пользовательские данные 2) На основе полученных пользовательских данных (п. 1) и секретного ключа снова генерирует jwt 3) Сравнивает jwt, полученный от пользователя, с jwt, который он сгенерировал на основе декодированных данных (п. 2) Если токены совпадают, клиентский сервер отдаёт запрашиваемые данные, если нет - ругается.

[@wce-tube]

​@@good_job_naumобъяснил идеально! 👍

[@НиколайЗаднепровский]

"Данные в JWT закодированы и подписаны, но не зашифрованы.". Зачем вообще говорить что что-то закодировано? Абсолютно вся инфромация в компьютерных системах закодирована так или иначе.

[@ShulV]

🤔🤔🤔 Не очень понятно как связаны auth server и app server, а именно - как сопоставляется access_token с пользователем в app server. Если в JWT access_token'а передается id пользователя, то это значит, что id пользователя хранится 2 раза, в auth server и в app server. Или у них общая БД? Какие данные хранятся в БД auth server'а, а какие в БД app server'а? При рассуждении о мастабируемости можно приплести сюда третий application server, который будет заниматься только данными пользователя. 🗨🗨🗨 Моё представление как должно быть сделано: 1) auth server хранит у себя в БД: логин, хэш пароля, идентификатор, время последнего входа, дата регистрации и тд, роль (при необходимости необходимые таблицы для ролей и разрешений для этих ролей) 2) auth application 1 (микросервис данных пользователей) хранит у себя в БД: идентификатор пользователя и прочие данные пользователя, которые не связаны с аутентификацией и авторизацией (пол, фио, номер телефона, почту...). 3) auth application 2 (микросервис определенной бизнес-задачи) хранит у себя в БД: все остальные бизнес-сущности. У сущностей, связанных с пользователем сохранен uuid пользователя. 4-*) auth application n (микросервис n-ой бизнес задачи) по аналогии с auth application 2 👁‍🗨👁‍🗨👁‍🗨 Итого: из дублирующихся данных только uuid пользователя во всех микросервисах, можно легко масштабироваться, создавая другие микросервисы, которые будут использовать этого пользователя. Единая система аутентификации. С авторизацией/правами пусть будет всё внутри auth сервера (чтобы не усложнять, а так для каждого микросервиса, наверное, нужны свои частые виды прав и разрешений)

[@IlyaSlezkin]

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

[@IlyaSlezkin]

ну и в токене уже будет вся инфа, юзер ид/роли

[@Be3dohannyy]

яндекс практикум помойка