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

Рет қаралды 28,811

Жыл бұрын

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

Пікірлер: 56

@MAGNet1911 Жыл бұрын

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

@losos6069 Жыл бұрын

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

@P_B_N_D 5 ай бұрын

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

@valbv Жыл бұрын

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

@falldimka123 Жыл бұрын

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

@Marat-Gasanian Жыл бұрын

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

@preegnees6664 Жыл бұрын

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

@user-fp7xm1zg1e Ай бұрын

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

@andriichornyi9143 5 ай бұрын

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

@ivkis3270 Жыл бұрын

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

@the-tata Жыл бұрын

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

@DmitriiRepnikov Жыл бұрын

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

@denisvladimirovich661 Жыл бұрын

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

@arahnid_9844 11 ай бұрын

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

@dmitrybabik8964 Жыл бұрын

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

@ksviety Жыл бұрын

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

@no101vmv Жыл бұрын

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

@ksviety Жыл бұрын

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

@PVBocs 6 ай бұрын

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

@user-ik5jz4yv5j Жыл бұрын

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

@redice8928 6 ай бұрын

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

@CELTRIX88 Жыл бұрын

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

@ilyakushlianski6519 Жыл бұрын

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

@MrLotrus Жыл бұрын

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

@kamnsv 2 ай бұрын

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

@golubevvictor Жыл бұрын

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

@nmatyasov4875 Жыл бұрын

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

@tatakai6827 9 ай бұрын

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

@unicoxr5tj417 Жыл бұрын

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

@shalidor1619 Жыл бұрын

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

@murat8757 Жыл бұрын

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

@user-db3gs1sc2v 7 ай бұрын

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

@unimaster3828 6 ай бұрын

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

@redice8928 6 ай бұрын

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

@geniusgabe8254 5 ай бұрын

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

@alexandr-v Жыл бұрын

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

@ohtori7339 Жыл бұрын

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

@user-ul5ic2rw5h Жыл бұрын

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

@user-ik5jz4yv5j Жыл бұрын

Что

@user-ul5ic2rw5h Жыл бұрын

@@user-ik5jz4yv5j Видос.

@p0z1ck Жыл бұрын

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

@username-forbidden 3 ай бұрын

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

@boycovclub Жыл бұрын

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

@MrLotrus Жыл бұрын

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

@sochilling Жыл бұрын

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

@user-fg6jw1cy5v 5 ай бұрын

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

@konstantinchvilyov9602 Жыл бұрын

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

@cr3wcabanger Жыл бұрын

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

@AUXLander Жыл бұрын

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

@nmatyasov4875 Жыл бұрын

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

@lollolich2399 Жыл бұрын

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

@viktor_borodin 7 ай бұрын

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

@wonderful2122 4 ай бұрын

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