Несколько нюансов: 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я опция, которая так же имеет свои проблемы и не удобства
@@dreksenthebest9738 это вы так думаете, но рефреш токен не посылается при каждом запросе, а используется только когда делается рефреш, так что при экспаире аксес токина сервер не знает валидный у тебя ревреш токен или нет. короче у нас в проде мы реализовали первый вариант, 2й со стаком слишком муторный. но как по правилам надо ОП в видео не рассказал.
В чем смысл refresh_token если мы его также с клиента передаем на сервер как и access_token? Вот если мы refresh запишем в куку как httponly и secure, то смысл появляется, так как сервер сам с ним взаисодействует и это безопасно потому что с клиента нет к нему доступа.
Я щапутался JWT незашифрован, но сервер расскодирует ключем. Так значит сам JWT зашифрован? или имелось ввиду что данние которие передаютса вместе с JWT не зашифрованние? и Какой смисл в JWT тогда если данние не шефруютса. Я могу же перехватить токен и ево использовать с другим телом запроса. Както не особо понятно
Ну там ничего сложного: делаем один токен для доступа (access), который мало живёт, и делаем долгоживущий refresh-токен. Пользователь ходит в приложение с access-токеном, пока тот не просрочится, а как просрочится, то кидает в приложение refresh-токен, чтобы перевыпустить access-токен.
Если по итогу данные в 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) Если токены совпадают, клиентский сервер отдаёт запрашиваемые данные, если нет - ругается.
🤔🤔🤔 Не очень понятно как связаны 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 сервера (чтобы не усложнять, а так для каждого микросервиса, наверное, нужны свои частые виды прав и разрешений)
"Данные в JWT закодированы и подписаны, но не зашифрованы.". Зачем вообще говорить что что-то закодировано? Абсолютно вся инфромация в компьютерных системах закодирована так или иначе.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Даешь OAuth и OpenID для народа!
Понял, беру на заметку 👌
@@ListenIT_channel Очень было бы интересно посмотреть реализацию и API запросы при использовании этих технологий🤩😍
А вот и OAuth и OpenID в новом видео th-cam.com/video/W_ffwyefi8A/w-d-xo.html
Спасибо за видео! Интересно и констурктивно подана информация. Теперь и правда хочется послушать про OAuth и OpenID 😊
А вот и OAuth и OpenID подъехали th-cam.com/video/W_ffwyefi8A/w-d-xo.html
спасибо большое, было довольно понятно и ясно
после этого видео необходимо сравнение session-cookis vs jwt)
Чувак спасибо за твои видосы !
Спасибо, что смотришь! И спасибо авторам статей, конечно.
канал заебись💥 очень хотел бы услышать про OAuth, и про тему разницы хеширования и кодирования
Ок, будет 👌
А вот и OAuth и OpenID подъехали th-cam.com/video/W_ffwyefi8A/w-d-xo.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я опция, которая так же имеет свои проблемы и не удобства
@@VadimBryksin во второй опции запрос не фейлится, так как рефреш верный, и к тому же выдается новый аксесс токен (я так думаю)
@@dreksenthebest9738 это вы так думаете, но рефреш токен не посылается при каждом запросе, а используется только когда делается рефреш, так что при экспаире аксес токина сервер не знает валидный у тебя ревреш токен или нет.
короче у нас в проде мы реализовали первый вариант, 2й со стаком слишком муторный. но как по правилам надо ОП в видео не рассказал.
Даёшь OpenAPI 3.0 !☝️
ну если так терминологию использовать то шифрование делаетса методом кодирования, что означает что данние в JWT зашифрованние
Тема JWT и микросервисов не бьіла затронута, как по-моему очень важная тема
Это да, так как это база!
В чем смысл refresh_token если мы его также с клиента передаем на сервер как и access_token?
Вот если мы refresh запишем в куку как httponly и secure, то смысл появляется, так как сервер сам с ним взаисодействует и это безопасно потому что с клиента нет к нему доступа.
Refresh так и передается же в куках с httponly secure, а так да реально нету смысла передавать если как access
Я щапутался JWT незашифрован, но сервер расскодирует ключем. Так значит сам JWT зашифрован? или имелось ввиду что данние которие передаютса вместе с JWT не зашифрованние? и Какой смисл в JWT тогда если данние не шефруютса. Я могу же перехватить токен и ево использовать с другим телом запроса. Както не особо понятно
Что за звук, который играет в заставке в первую секунду? Очень знакомый, но не могу понять из какой игры ... Starcraft ?
Подсказка: в этом звуке участвуют слова "палатка" и "помощь"...)
@@ListenIT_channel Все, спасибо!)) Сразу понял) Герои 3
спасибо)
благодарю
Можно ещё записать видео))))
про рефрештокен я запутался)
Ну там ничего сложного: делаем один токен для доступа (access), который мало живёт, и делаем долгоживущий refresh-токен. Пользователь ходит в приложение с access-токеном, пока тот не просрочится, а как просрочится, то кидает в приложение refresh-токен, чтобы перевыпустить access-токен.
Спасибо!
Хотим перевод статьи про кодирование и шифрование !
Интересно
Если по итогу данные в 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 минут спустя...
- Ну, посмотрите на экран
😅
Всё-таки не очень будет классно звучать, если в статье озвучивать токен)
🤔🤔🤔
Не очень понятно как связаны 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 сервера (чтобы не усложнять, а так для каждого микросервиса, наверное, нужны свои частые виды прав и разрешений)
так когда апп провалидировала токен, зачем ему ещё какие то данные если понятно что токен не поддельный?
ну и в токене уже будет вся инфа, юзер ид/роли
Большой интерес в комментариях - проснулся
"Данные в JWT закодированы и подписаны, но не зашифрованы.". Зачем вообще говорить что что-то закодировано? Абсолютно вся инфромация в компьютерных системах закодирована так или иначе.
тестировщики здесь 🤙🏻🤙🏻
яндекс практикум помойка