Что такое JWT и как его создать
Рет қаралды 39,986
Жыл бұрынОсваивайте новые навыки и технологии на курсах от Яндекс Практикум - clck.ru/34Bx53
В этой статье мы узнаем:
- Что такое JWT
- Из каких частей состоит JWT
- Как создать JWT
- Как генерируется подпись в JWT
- Чем хорош JWT
- Безопасноcть JWT
- Советы по применению JWT
- Что такое refresh token
Поддержать канал разово - yoomoney.ru/to/410012243709514
Поддержать канал подпиской - boosty.to/listenit
Я.Дзен - zen.yandex.ru/listenit
Телеграм-канал - t.me/listenit_channel
События и статьи про анализ и проектирование ИТ-систем - t.me/itsysdes_events
По вопросам сотрудничества - t.me/ed_akimov
Ссылка на статью 1 - habr.com/ru/articles/340146/
Ссылка на статью 2 - struchkov.dev/blog/ru/what-is...
Что такое ELK за 10 минут - • Что такое ELK за 10 ми...
Что такое МИКРОФРОНТЕНД за 10 минут - • Что такое МИКРОФРОНТЕН...
Различия SOA и микросервисной архитектуры за 9 минут - • Различия SOA и микросе...
Компиляция и интерпретация за 10 минут - • Компиляция и интерпрет...
Что такое TypeScript за 9 минут - • Что такое TypeScript з...
Что такое Swagger и OpenAPI за 3 минуты - • Что такое Swagger и Op...
Введение в REST API за 7 минут - • Введение в REST API за...
Различия REST и SOAP за 4 минуты - • Различия REST и SOAP з...
Что такое HTTP и HTTPS за 9 минут - • Что такое HTTP и HTTPS...
Что такое TCP/IP - • Что такое TCP/IP: Объя...
Что такое прокси-сервер за 7 минут - • Что такое прокси-серве...
Что такое Kubernetes за 9 минут - • Что такое Kubernetes з...
Что такое Docker за 5 минут - • Что такое Docker за 5 ...
Что такое Big Data за 6 минут - • Что такое Big Data за ...
Что такое SQL и реляционные базы данных - • Что такое SQL и реляци...
Что такое NoSQL за 6 минут - • Что такое NoSQL за 6 м...
Синтаксис SQL запросов: Часть 1 - • Синтаксис SQL запросов...
Что такое SQL ИНДЕКСЫ за 10 минут - • Что такое SQL ИНДЕКСЫ ...
Что такое ETL и ELT за 10 минут - • Что такое ETL и ELT за...
Что такое CRUD за 6 минут - • Что такое CRUD за 6 минут
Что такое middleware за 7 минут - • Что такое middleware з...
Что такое идемпотентность - • Что такое идемпотентно...
Что такое ACID за 9 минут - • Что такое ACID за 9 минут
Что такое HATEOAS за 4 минуты - • Что такое HATEOAS за 4...
Что такое CI/CD - • Что такое CI/CD? Разби...
Что такое Code First подход за 4 минуты - • Что такое Code First п...
Что такое Contract First подход за 4 минуты - • Что такое Contract Fir...
4CQwVszH9pSaL55hkDt
@Jay82rus Жыл бұрын
Даешь OAuth и OpenID для народа!
@ListenIT_channel Жыл бұрын
Понял, беру на заметку 👌
@bennails3447 Жыл бұрын
@@ListenIT_channel Очень было бы интересно посмотреть реализацию и API запросы при использовании этих технологий🤩😍
@ListenIT_channel 11 ай бұрын
А вот и OAuth и OpenID в новом видео kzfaq.info/get/bejne/jcWWmdqqyszNaHU.html
@valerysilakov3498 Жыл бұрын
Спасибо за видео! Интересно и констурктивно подана информация. Теперь и правда хочется послушать про OAuth и OpenID 😊
@ListenIT_channel 11 ай бұрын
А вот и OAuth и OpenID подъехали kzfaq.info/get/bejne/jcWWmdqqyszNaHU.html
@nikitabbrv5947 Жыл бұрын
после этого видео необходимо сравнение session-cookis vs jwt)
@citizen1184 Жыл бұрын
Супер. Спасибо!
@vitaliySobakinson Жыл бұрын
Как всегда супер)
@bublck-gt1lo Жыл бұрын
Чувак спасибо за твои видосы !
@ListenIT_channel Жыл бұрын
Спасибо, что смотришь! И спасибо авторам статей, конечно.
@HeyWhoTheFuckAreYou Жыл бұрын
Ну раз дело до JWT дошло, то давай про сервисы авторизации, OAuth, OpenID Connect всякие защиты аля PKCE
@ListenIT_channel Жыл бұрын
Услышал, вполне можно записать 👌
@ListenIT_channel 11 ай бұрын
А вот и OAuth и OpenID подъехали kzfaq.info/get/bejne/jcWWmdqqyszNaHU.html
@limeniye Жыл бұрын
Тема JWT и микросервисов не бьіла затронута, как по-моему очень важная тема
@andrewkotov3234 11 ай бұрын
Это да, так как это база!
@futureghost2929 Жыл бұрын
канал заебись💥 очень хотел бы услышать про OAuth, и про тему разницы хеширования и кодирования
@ListenIT_channel Жыл бұрын
Ок, будет 👌
@ListenIT_channel 11 ай бұрын
А вот и OAuth и OpenID подъехали kzfaq.info/get/bejne/jcWWmdqqyszNaHU.html
@VadimBryksin 8 ай бұрын
Несколько нюансов: 1) если напихать слишком много данных в клэйм токена, то токен может превысить лимит хэдера в HTTP запросе, так что размер JWT все-таки конечный, лично сталкивались и приходилось лимитировать... 2) по рефреш токену - тема не раскрыта, кто должен мониторить за экспаирлися токен или нет? * если клиент, то это должен быть какой-то крон на клиентской стороне (допустим раз в минуту) который по тригеру будет рефрешить токен, но тогда нужно мониторить активность юзера и отрубать ежеминутный крон как только юзер стал не активным. * или клиент всегда делает запрос с токеном что у него сейчас есть и в ответ получает 401 потому что токен за экспаирился? и только в этом случае клиент рефрешит аксеес токен? а что с запросом который уже за фэилился? это нужно тогда иметь какой-то локальный стак на клиенте, куда складывать все отправленные запросы чтоб в случае с 401, можно было за рефрешить токен и пере повторить запрос из сохраненного стака? + менеджить стак чистя его при успешых запросах * может еще какие-то варианты есть? Как правильно то?
@tami-he4mm 6 ай бұрын
Я думаю не обязательно мониторить, к примеру возьмем такой пример: у тебя истек 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 6 ай бұрын
@@tami-he4mm полагаю вы не очень внимательно прочитали мой оригинальный пост? То что вы описываете я так же описал как 2я опция, которая так же имеет свои проблемы и не удобства
@spadar1602 Жыл бұрын
В чем смысл refresh_token если мы его также с клиента передаем на сервер как и access_token? Вот если мы refresh запишем в куку как httponly и secure, то смысл появляется, так как сервер сам с ним взаисодействует и это безопасно потому что с клиента нет к нему доступа.
@nurlytan_berikbol 11 ай бұрын
Refresh так и передается же в куках с httponly secure, а так да реально нету смысла передавать если как access
@linkerloader47 Жыл бұрын
Даёшь OpenAPI 3.0 !☝️
@Kirill.Bogdanovich Жыл бұрын
благодарю
@ShulV 27 күн бұрын
🤔🤔🤔 Не очень понятно как связаны 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 сервера (чтобы не усложнять, а так для каждого микросервиса, наверное, нужны свои частые виды прав и разрешений)
@MrShevrin Жыл бұрын
про рефрештокен я запутался)
@ListenIT_channel Жыл бұрын
Ну там ничего сложного: делаем один токен для доступа (access), который мало живёт, и делаем долгоживущий refresh-токен. Пользователь ходит в приложение с access-токеном, пока тот не просрочится, а как просрочится, то кидает в приложение refresh-токен, чтобы перевыпустить access-токен.
@dariavadimovna8611 7 ай бұрын
спасибо)
@user-zx7xe1cb2c Жыл бұрын
Интересно
@irker8220 Жыл бұрын
Что за звук, который играет в заставке в первую секунду? Очень знакомый, но не могу понять из какой игры ... Starcraft ?
@ListenIT_channel Жыл бұрын
Подсказка: в этом звуке участвуют слова "палатка" и "помощь"...)
@irker8220 Жыл бұрын
@@ListenIT_channel Все, спасибо!)) Сразу понял) Герои 3
@robert33232 2 ай бұрын
Спасибо!
@user-ii5jj5sc8p 10 ай бұрын
Хотим перевод статьи про кодирование и шифрование !
@nickfox5394 Жыл бұрын
Можно ещё записать видео))))
@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) Если токены совпадают, клиентский сервер отдаёт запрашиваемые данные, если нет - ругается.
@yandoru Жыл бұрын
@@good_job_naumобъяснил идеально! 👍
@yandoru Жыл бұрын
- Ну, слушайте статью из мира IT (LISTEN IT) ...5 минут спустя... - Ну, посмотрите на экран 😅
@ListenIT_channel Жыл бұрын
Всё-таки не очень будет классно звучать, если в статье озвучивать токен)
@yandoru Жыл бұрын
Большой интерес в комментариях - проснулся
@chickeneffect 11 ай бұрын
тестировщики здесь 🤙🏻🤙🏻
@user-vx6zk5jj4e 11 ай бұрын
"Данные в JWT закодированы и подписаны, но не зашифрованы.". Зачем вообще говорить что что-то закодировано? Абсолютно вся инфромация в компьютерных системах закодирована так или иначе.
@finjakeoff5957 10 ай бұрын
яндекс практикум помойка
Go Gizmo!
Рет қаралды 28 МЛН
David Dobryakov
Рет қаралды 65 М.