JWT как строить архитектуру

#soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...

[@MAGNet1911]

было бы не плохо оставлять ссылку на предыдущее видео по теме где-нибудь в описании или в первом, закреплённом комментарии. спасибо.

[@P_B_N_D]

Отличный разбор темы!👍👍👍 Понятно , последовательно, подробно! Я как человек, который до этого ничего не знал о токенах, понял все, что было сказано в видео.

[@losos6069]

10 из 10, спасибо за годный контент!

[@valbv]

Посмотрел с удовольствием! Было бы интересно ещё узнать про архитектурные решения для областей, где цена компроментации токена может быть очень большой (Фин.тех., медицина) Первое что приходит в голову использовать ассиметричное шифрование данных, но наверняка есть варианты поинтереснее

[@dmitrybabik8964]

а какие более безопасные альтернативы jwt токену предлагаются?

[@ksviety]

аутентификация каждого критического действия, наверно, безопасней

[@no101vmv]

Каким образом? Через ввод логина пароля?

[@ksviety]

@@no101vmv Ну много вариантов. например одноразовый код. Это конечно, немного разное - JWT и безопасность, но все же. Просто в токене не нужно передавать чувствительные данные, а сам токен можно выдавать под каждое (только одно) действие, и проверять подпись, разумеется. Приемущиство JWT просто в том, что не нужно на каждый запрос ходить в сервис аутентификации для его валидации, а сам сервис не должен эти токены хранить в базе данных. А, чтобы токеном не мог воспользоваться кто-то другой, например, можно цифровой отпечаток в токен сунуть (и подделать его будет нельзя, из-за подписи) - хотя бы тот же IP или еще, что нибудь придумать. Главное не делать этого с refresh токеном, а то подобные отпечатки в нем приведут к постоянной необходимости в аутентификации. В целом TLS, RS512, отпечаток, и одноразовасть токена выглядит безопасно. Однако если делать токены одноразовыми (например, через поле jti), то сервису, его выдавшему все же придется хранить эти токены, как использованные, а сервису, который использует эти токены для авторизации действия придется ходить в сервис аутентификации для валидации и инвалидации токенов. Так же если все таки нужно шифровать данные в токене, то JWS, вроде как это поддерживает (спецификация)

[@PVBocs]

​@@no101vmvодноразовые пароли?

[@abilvap5611]

​@@no101vmvчерез токен сессии , если он не истек и совпадает со значением в бд то по сути пользователь уже авторизовался недавно

[@Marat-Gasanian]

Спасибо за интересное видео 😊

[@falldimka123]

Как вовремя, спасибо

[@the-tata]

Сойер, верни пожалуйста ночной стрим. Он нереально был крут.

[@arahnid_9844]

Какие есть альтернативы для обеспечения большей безопасности?

[@andriichornyi9143]

Зачетное видео.

[@den-vm]

Было бы не плохо узнать об oauth2.0 особенно в NET 5, 6(Если есть разница конечно же)

[@DmitriiRepnikov]

5:39 то что происходит в моей голове, когда я пытаюсь врубиться в новую для себя технологию

[@artmus208]

По сути, после пятой минуты уже начинается задел на OAuth, было бы славно, если сказали бы об этом явно

[@unicoxr5tj417]

а будет ли практика? Покодировать авторизацию-аутентификацию?

[@shalidor1619]

Эт кодить надо, а не языком честь, ты чего))

[@MiroslavGeidt]

Это просто оху...!!

[@preegnees6664]

Здравствуйте, а можно для read-only использовать access token, а чтобы нажать, как пример, на какую-нибудь кнопку нужно использовать refresh token?

[@golubevvictor]

RT формируется по тем же правилам, что и АТ, только с другим ключём?

[@nmatyasov4875]

Да, ключ естественно другой и время жизни, payload по вкусу

[@K392-f4k]

Спасибо что рассказали. Хоть где-то можно элементарно узнать теорию о jwt

[@redice8928]

да она повсюду

[@ivkis3270]

спасибо, очень полезное видео. Давно задавался вопросом, где хранить токены и что делать, если его украдут)

[@CELTRIX88]

подскажите, как отдельный микросервис проверяет валидность access токена?

[@ilyakushlianski6519]

по идее сервис должен знать секрет. Когда присылаем ему payload + signature, сервис берем payload и с помощью секрета подписывает его и получает свою signature. Если переданная и рассчитанная signature совпадают, то значит токен валиден

[@MrLotrus]

@@ilyakushlianski6519 Секрет нужен для шифрования токена. А для валидации публичный ключ. Вот им уже можно делиться с другими приложениями.

[@mtvspec]

@@MrLotrus публичный ключ это один из вариантов

[@murat8757]

Где Ночное Видео?????? Про Монолитныую Архетиктуру....и.п...... Чуть осталось Досмотреть!!!!

[@konstantinchvilyov9602]

Мысли, конечно, интересные и, вероятно, оригинальные. Но вы сами напросились на вопросы :) 1.Есть масса уже принятых и проверенных стандартов(протоколов) с использованием JWT. Не исключено, что вы предлагаете ещё лучше. Но чтобы это понять надо увидеть сравнение с существующими. Или я пропустил? 2.В как минимум одном из стандартов освежающий жетон(refresh token) используется только один раз для получения новой пары жетонов. И это даёт возможность быстро обнаружить его повторное использование, в отличие от предлагаемого вами многократного использования refresh token. Почему вы не используете это известное решение? 3.По поводу поддержки сессии: 3.1.Вы связываете освежающий жетон(refresh token) с сессией в приложении? 3.2.Если да, то как передаёте эту информацию в приложение? 3.3.Если заново установили подлинность(authenticate) и получили новый освежающий жетон(refresh token) то считаете началась новая сессия в приложении?

[@unimaster3828]

Я правильно понял, что 1RT = много AT? И вообще я практикую сейчас архитектуру, где RT - это JWT c AT. Когда срок AT приходит к концу, то с помощью RT запрашивается новая пара AT и RT, старые AT (инфу о том, что именно он просрочился я беру из RT) и RT помечаются как отозванные. Т.е 1RT = 1 новый RT = 1 AT.

[@mtvspec]

я так понимаю что AT обновляется с помощью RT, RT может обновляться в этот момент (продлеваться), получается что RT должен храниться на стороне сервера, интересно, если будут миллионы запросов, к разным сервисам (если это микросервисная архитектура), то какие есть возможности оптимизации процесса обновления AT и RT, AT обычно имеет короткий срок жизни, поэтому запросов на обновление AT может быть очень много, если к серверу подключено большое количество сессий

[@kamnsv]

Как SERVICE поймет что AT действительный?

[@mtvspec]

токен подписан подписью, на стороне сервиса должна быть подпись с помощью которой сервис может проверить, что токен валидный

[@redice8928]

а при первом запросе пара логин и пароль не шифруется? А если шифруется, то как сервер понимает как это нужно расшифровать?

[@geniusgabe8254]

А смысл, если всё передаётся по https

[@tatakai6827]

Знает кто нибудь статью или гайд как реализовать подобную архитектуру на spring boot?

[@cr3wcabanger]

а если при выдаче access_token добавлять в него ip клиента и проверять в сервисах ip из запроса с тем что лежит в jwt? По идее это же добавит безопасности, но не решает проблему целиком. В таком случае, если у нас в сервис придет не тот адрес мы можем послать сообщение на инвалидацию RT и перелогин пользователя.

[@AUXLander]

Вероятно, что в таком случае токен будет инвалидироваться слишком часто в мобильных устройствах

[@nmatyasov4875]

В видео не рассмотрен вопрос как вход/доступ с нескольких устройств (рабочий комп/домашний/ноут) или смартфона, те ip постоянно меняется, те надо делать коллекцию RT пользователя, где-то хранить, проверять "протухшие" и тп и тд, так что возни много

[@alexandr-v]

А как пользователь получает secret?

[@ohtori7339]

Если имеется ввиду клиент, то никак.

[@boycovclub]

А что вы скажете про такую архитектуру. Насколько она безопасна. При регистрации, авторизации сервер выдает согласно логину и пароль закодированнный сигнатурой ключевого слова токен. Дальше токен на клиенте хранится в локалсторидже. Далее при каждом запросе в интерсепторах или мидлвере в заголовке мы кладем токен закодированный. А на стороне сервера перед доступом к сервисам роутов мы делаем проверку гуардс во фрейморке на токен парсим его и проверяем в БД есть ли такой пользователь с таким логином и паролем, и дальше даем доступ к апи. Тут смысл в этом что токен один.

[@MrLotrus]

Теряется смысл использования JWT, если при каждом запросе надо лезть в БД.

[@sochilling]

@@MrLotrusВсмысле? Так в токене лежит к примеру userId, мы отправляем запрос на получение к примеру постов пользователя, в запросе отправляем токен, на сервере в данных с jwt получаем userId и по этому айди ищем посты у которых userId автора совпадает с userId который пришёл в запросе. О каком смысле jwt с бд ты говоришь?

[@SpockSynckov]

@@sochilling у тя уже есть подпись токена, которая на стороне сервера делается, просто клади в payload доп инфу, типа ролей

[@p0z1ck]

Передача refresh token на клиенскую сторону плохая идея, потому что в случае его утечки, третье лицо сможет пользоваться им бесконечно, отозвать будет очень сложно и не быстро.

[@username-forbidden]

Нужно делать чёрные или белые списки рефреш токенов в базе и во время каждого рефреша проверять по наличию в базе. Так же в профиле/аккаунте пользователя нужно сделать кнопку "Выйти на других устройствах", которая инвалидирует остальные токены этого пользователя из белого списка.

[@IS-sm3kp]

@@username-forbidden доп списки доп нагрузки

[@lollolich2399]

А что если мы будем хранить в рефреш токене ip адрес и девайс, с которого произошёл логин, и шифровать этот токен. Далее представим злоумышленник украл рефреш токен и пытается получить новый рефреш токен. Об cодержание токена, то есть об ip адресе и девайсе ему ничего не известно в силу того, что токен - это какая-та зашифрованная строка. Мы получаем от него украденный рефреш токен, дешифруем его, сверяем айпи адрес и девайс запроса с соответствующими значениями в токене, если проверка не прошла, то отклоняем запрос, иначе, то есть запрос на новый рефреш токен делает исходный юзер, что и получил изначальный рефреш токен, тогда выдаём новый рефреш токен. Какие подводные камни у такой схемы?

[@viktor_borodin]

Возможны, ситуации как я понимаю, когда ip может меняться слишком часто. Например, в случае мобильной связи

[@wonderful2122]

Злоумышленник все знает о ip и девайсе. Шифруется только secret, Payload просто использует HS256 или что-то еще.

[@akaZarj]

так и не сказал что использовать вместо jwt там где его нельзя использовать...

[@wonderful2122]

Сессии

[@ИванНикитин-ч7б]

Со склейками, правками и редактурой.

[@K392-f4k]

Что

[@ИванНикитин-ч7б]

@@K392-f4k Видос.

[@14types]

Какое-то лицо сглаженное и осветлённое, смотрится как-то не оч