Что такое JWT и как его создать
HTML-код
- Опубликовано: 19 апр 2023
- Осваивайте новые навыки и технологии на курсах от Яндекс Практикум - 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
![[adult swim] - Smiling Friends Season 2 Episode 5 Promo](http://i.ytimg.com/vi/uStNEeR8LT4/mqdefault.jpg)
Даешь OAuth и OpenID для народа!
Понял, беру на заметку 👌
@@ListenIT_channel Очень было бы интересно посмотреть реализацию и API запросы при использовании этих технологий🤩😍
А вот и OAuth и OpenID в новом видео ruclips.net/video/W_ffwyefi8A/видео.html
Спасибо за видео! Интересно и констурктивно подана информация. Теперь и правда хочется послушать про OAuth и OpenID 😊
А вот и OAuth и OpenID подъехали ruclips.net/video/W_ffwyefi8A/видео.html
после этого видео необходимо сравнение session-cookis vs jwt)
Ну раз дело до JWT дошло, то давай про сервисы авторизации, OAuth, OpenID Connect всякие защиты аля PKCE
Услышал, вполне можно записать 👌
А вот и OAuth и OpenID подъехали ruclips.net/video/W_ffwyefi8A/видео.html
Супер. Спасибо!
Как всегда супер)
Чувак спасибо за твои видосы !
Спасибо, что смотришь! И спасибо авторам статей, конечно.
Несколько нюансов:
1) если напихать слишком много данных в клэйм токена, то токен может превысить лимит хэдера в HTTP запросе, так что размер JWT все-таки конечный, лично сталкивались и приходилось лимитировать...
2) по рефреш токену - тема не раскрыта, кто должен мониторить за экспаирлися токен или нет?
* если клиент, то это должен быть какой-то крон на клиентской стороне (допустим раз в минуту) который по тригеру будет рефрешить токен, но тогда нужно мониторить активность юзера и отрубать ежеминутный крон как только юзер стал не активным.
* или клиент всегда делает запрос с токеном что у него сейчас есть и в ответ получает 401 потому что токен за экспаирился? и только в этом случае клиент рефрешит аксеес токен? а что с запросом который уже за фэилился? это нужно тогда иметь какой-то локальный стак на клиенте, куда складывать все отправленные запросы чтоб в случае с 401, можно было за рефрешить токен и пере повторить запрос из сохраненного стака? + менеджить стак чистя его при успешых запросах
* может еще какие-то варианты есть?
Как правильно то?
Я думаю не обязательно мониторить, к примеру возьмем такой пример:
у тебя истек 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 от сервера
@@tami-he4mm полагаю вы не очень внимательно прочитали мой оригинальный пост? То что вы описываете я так же описал как 2я опция, которая так же имеет свои проблемы и не удобства
канал заебись💥 очень хотел бы услышать про OAuth, и про тему разницы хеширования и кодирования
Ок, будет 👌
А вот и OAuth и OpenID подъехали ruclips.net/video/W_ffwyefi8A/видео.html
Тема JWT и микросервисов не бьіла затронута, как по-моему очень важная тема
Это да, так как это база!
🤔🤔🤔
Не очень понятно как связаны 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 сервера (чтобы не усложнять, а так для каждого микросервиса, наверное, нужны свои частые виды прав и разрешений)
Даёшь OpenAPI 3.0 !☝️
В чем смысл refresh_token если мы его также с клиента передаем на сервер как и access_token?
Вот если мы refresh запишем в куку как httponly и secure, то смысл появляется, так как сервер сам с ним взаисодействует и это безопасно потому что с клиента нет к нему доступа.
Refresh так и передается же в куках с httponly secure, а так да реально нету смысла передавать если как access
про рефрештокен я запутался)
Ну там ничего сложного: делаем один токен для доступа (access), который мало живёт, и делаем долгоживущий refresh-токен. Пользователь ходит в приложение с access-токеном, пока тот не просрочится, а как просрочится, то кидает в приложение refresh-токен, чтобы перевыпустить access-токен.
благодарю
Хотим перевод статьи про кодирование и шифрование !
спасибо)
Можно ещё записать видео))))
Что за звук, который играет в заставке в первую секунду? Очень знакомый, но не могу понять из какой игры ... Starcraft ?
Подсказка: в этом звуке участвуют слова "палатка" и "помощь"...)
@@ListenIT_channel Все, спасибо!)) Сразу понял) Герои 3
Интересно
Спасибо!
Если по итогу данные в JWT кодируются с помощью секретного ключа, который есть только на сервере и у пользователя, то почему по нему не безопасно передавать данные паспорта?
Если я правильно понял, header и payload шифруется c помощью base64. Т.е. любой, кто получит токен, может просто прогнать их через декодер и получить исходные данные. Именно шифруется только signature, но сама строка signature является теми самыми закодированными header и payload, соединёнными точкой. API при каждом запросе будет сравнивать в пришедшем JWT часть header.payload и расшифрованную с помощью секретного ключа signature. Если они равны, то проверка пройдёт успешно. Надеюсь, что понятно объяснил.
1. Секретный ключ есть только у сервера авторизации и клиентского сервера. У пользователя нет секретного ключа.
2. Хедер и пэйлоад не шифруются, они кодируются base64. Это значит, что с помощью декодера эти данные можно раскодировать.
Что, собственно, и делает клиентский сервер:
1) Декодирует хедер и пэйлоад и получает пользовательские данные
2) На основе полученных пользовательских данных (п. 1) и секретного ключа снова генерирует jwt
3) Сравнивает jwt, полученный от пользователя, с jwt, который он сгенерировал на основе декодированных данных (п. 2)
Если токены совпадают, клиентский сервер отдаёт запрашиваемые данные, если нет - ругается.
@@good_job_naumобъяснил идеально! 👍
- Ну, слушайте статью из мира IT (LISTEN IT)
...5 минут спустя...
- Ну, посмотрите на экран
😅
Всё-таки не очень будет классно звучать, если в статье озвучивать токен)
Большой интерес в комментариях - проснулся
тестировщики здесь 🤙🏻🤙🏻
"Данные в JWT закодированы и подписаны, но не зашифрованы.". Зачем вообще говорить что что-то закодировано? Абсолютно вся инфромация в компьютерных системах закодирована так или иначе.
яндекс практикум помойка