Посмотрел с удовольствием! Было бы интересно ещё узнать про архитектурные решения для областей, где цена компроментации токена может быть очень большой (Фин.тех., медицина) Первое что приходит в голову использовать ассиметричное шифрование данных, но наверняка есть варианты поинтереснее
Отличный разбор темы!👍👍👍 Понятно , последовательно, подробно! Я как человек, который до этого ничего не знал о токенах, понял все, что было сказано в видео.
@@no101vmv Ну много вариантов. например одноразовый код. Это конечно, немного разное - JWT и безопасность, но все же. Просто в токене не нужно передавать чувствительные данные, а сам токен можно выдавать под каждое (только одно) действие, и проверять подпись, разумеется. Приемущиство JWT просто в том, что не нужно на каждый запрос ходить в сервис аутентификации для его валидации, а сам сервис не должен эти токены хранить в базе данных. А, чтобы токеном не мог воспользоваться кто-то другой, например, можно цифровой отпечаток в токен сунуть (и подделать его будет нельзя, из-за подписи) - хотя бы тот же IP или еще, что нибудь придумать. Главное не делать этого с refresh токеном, а то подобные отпечатки в нем приведут к постоянной необходимости в аутентификации. В целом TLS, RS512, отпечаток, и одноразовасть токена выглядит безопасно. Однако если делать токены одноразовыми (например, через поле jti), то сервису, его выдавшему все же придется хранить эти токены, как использованные, а сервису, который использует эти токены для авторизации действия придется ходить в сервис аутентификации для валидации и инвалидации токенов. Так же если все таки нужно шифровать данные в токене, то JWS, вроде как это поддерживает (спецификация)
Я правильно понял, что 1RT = много AT? И вообще я практикую сейчас архитектуру, где RT - это JWT c AT. Когда срок AT приходит к концу, то с помощью RT запрашивается новая пара AT и RT, старые AT (инфу о том, что именно он просрочился я беру из RT) и RT помечаются как отозванные. Т.е 1RT = 1 новый RT = 1 AT.
я так понимаю что AT обновляется с помощью RT, RT может обновляться в этот момент (продлеваться), получается что RT должен храниться на стороне сервера, интересно, если будут миллионы запросов, к разным сервисам (если это микросервисная архитектура), то какие есть возможности оптимизации процесса обновления AT и RT, AT обычно имеет короткий срок жизни, поэтому запросов на обновление AT может быть очень много, если к серверу подключено большое количество сессий
по идее сервис должен знать секрет. Когда присылаем ему payload + signature, сервис берем payload и с помощью секрета подписывает его и получает свою signature. Если переданная и рассчитанная signature совпадают, то значит токен валиден
Мысли, конечно, интересные и, вероятно, оригинальные. Но вы сами напросились на вопросы :) 1.Есть масса уже принятых и проверенных стандартов(протоколов) с использованием JWT. Не исключено, что вы предлагаете ещё лучше. Но чтобы это понять надо увидеть сравнение с существующими. Или я пропустил? 2.В как минимум одном из стандартов освежающий жетон(refresh token) используется только один раз для получения новой пары жетонов. И это даёт возможность быстро обнаружить его повторное использование, в отличие от предлагаемого вами многократного использования refresh token. Почему вы не используете это известное решение? 3.По поводу поддержки сессии: 3.1.Вы связываете освежающий жетон(refresh token) с сессией в приложении? 3.2.Если да, то как передаёте эту информацию в приложение? 3.3.Если заново установили подлинность(authenticate) и получили новый освежающий жетон(refresh token) то считаете началась новая сессия в приложении?
а если при выдаче access_token добавлять в него ip клиента и проверять в сервисах ip из запроса с тем что лежит в jwt? По идее это же добавит безопасности, но не решает проблему целиком. В таком случае, если у нас в сервис придет не тот адрес мы можем послать сообщение на инвалидацию RT и перелогин пользователя.
В видео не рассмотрен вопрос как вход/доступ с нескольких устройств (рабочий комп/домашний/ноут) или смартфона, те ip постоянно меняется, те надо делать коллекцию RT пользователя, где-то хранить, проверять "протухшие" и тп и тд, так что возни много
А что вы скажете про такую архитектуру. Насколько она безопасна. При регистрации, авторизации сервер выдает согласно логину и пароль закодированнный сигнатурой ключевого слова токен. Дальше токен на клиенте хранится в локалсторидже. Далее при каждом запросе в интерсепторах или мидлвере в заголовке мы кладем токен закодированный. А на стороне сервера перед доступом к сервисам роутов мы делаем проверку гуардс во фрейморке на токен парсим его и проверяем в БД есть ли такой пользователь с таким логином и паролем, и дальше даем доступ к апи. Тут смысл в этом что токен один.
@@MrLotrusВсмысле? Так в токене лежит к примеру userId, мы отправляем запрос на получение к примеру постов пользователя, в запросе отправляем токен, на сервере в данных с jwt получаем userId и по этому айди ищем посты у которых userId автора совпадает с userId который пришёл в запросе. О каком смысле jwt с бд ты говоришь?
Передача refresh token на клиенскую сторону плохая идея, потому что в случае его утечки, третье лицо сможет пользоваться им бесконечно, отозвать будет очень сложно и не быстро.
Нужно делать чёрные или белые списки рефреш токенов в базе и во время каждого рефреша проверять по наличию в базе. Так же в профиле/аккаунте пользователя нужно сделать кнопку "Выйти на других устройствах", которая инвалидирует остальные токены этого пользователя из белого списка.
А что если мы будем хранить в рефреш токене ip адрес и девайс, с которого произошёл логин, и шифровать этот токен. Далее представим злоумышленник украл рефреш токен и пытается получить новый рефреш токен. Об cодержание токена, то есть об ip адресе и девайсе ему ничего не известно в силу того, что токен - это какая-та зашифрованная строка. Мы получаем от него украденный рефреш токен, дешифруем его, сверяем айпи адрес и девайс запроса с соответствующими значениями в токене, если проверка не прошла, то отклоняем запрос, иначе, то есть запрос на новый рефреш токен делает исходный юзер, что и получил изначальный рефреш токен, тогда выдаём новый рефреш токен. Какие подводные камни у такой схемы?
было бы не плохо оставлять ссылку на предыдущее видео по теме где-нибудь в описании или в первом, закреплённом комментарии.
спасибо.
10 из 10, спасибо за годный контент!
Посмотрел с удовольствием!
Было бы интересно ещё узнать про архитектурные решения для областей, где цена компроментации токена может быть очень большой (Фин.тех., медицина)
Первое что приходит в голову использовать ассиметричное шифрование данных, но наверняка есть варианты поинтереснее
Отличный разбор темы!👍👍👍 Понятно , последовательно, подробно! Я как человек, который до этого ничего не знал о токенах, понял все, что было сказано в видео.
Спасибо за интересное видео 😊
Как вовремя, спасибо
а какие более безопасные альтернативы jwt токену предлагаются?
аутентификация каждого критического действия, наверно, безопасней
Каким образом? Через ввод логина пароля?
@@no101vmv Ну много вариантов. например одноразовый код. Это конечно, немного разное - JWT и безопасность, но все же. Просто в токене не нужно передавать чувствительные данные, а сам токен можно выдавать под каждое (только одно) действие, и проверять подпись, разумеется.
Приемущиство JWT просто в том, что не нужно на каждый запрос ходить в сервис аутентификации для его валидации, а сам сервис не должен эти токены хранить в базе данных.
А, чтобы токеном не мог воспользоваться кто-то другой, например, можно цифровой отпечаток в токен сунуть (и подделать его будет нельзя, из-за подписи) - хотя бы тот же IP или еще, что нибудь придумать. Главное не делать этого с refresh токеном, а то подобные отпечатки в нем приведут к постоянной необходимости в аутентификации.
В целом TLS, RS512, отпечаток, и одноразовасть токена выглядит безопасно.
Однако если делать токены одноразовыми (например, через поле jti), то сервису, его выдавшему все же придется хранить эти токены, как использованные, а сервису, который использует эти токены для авторизации действия придется ходить в сервис аутентификации для валидации и инвалидации токенов.
Так же если все таки нужно шифровать данные в токене, то JWS, вроде как это поддерживает (спецификация)
@@no101vmvодноразовые пароли?
@@no101vmvчерез токен сессии , если он не истек и совпадает со значением в бд то по сути пользователь уже авторизовался недавно
Было бы не плохо узнать об oauth2.0 особенно в NET 5, 6(Если есть разница конечно же)
Какие есть альтернативы для обеспечения большей безопасности?
Зачетное видео.
а будет ли практика? Покодировать авторизацию-аутентификацию?
Эт кодить надо, а не языком честь, ты чего))
Сойер, верни пожалуйста ночной стрим. Он нереально был крут.
Здравствуйте, а можно для read-only использовать access token, а чтобы нажать, как пример, на какую-нибудь кнопку нужно использовать refresh token?
5:39 то что происходит в моей голове, когда я пытаюсь врубиться в новую для себя технологию
RT формируется по тем же правилам, что и АТ, только с другим ключём?
Да, ключ естественно другой и время жизни, payload по вкусу
спасибо, очень полезное видео. Давно задавался вопросом, где хранить токены и что делать, если его украдут)
Это просто оху...!!
По сути, после пятой минуты уже начинается задел на OAuth, было бы славно, если сказали бы об этом явно
Спасибо что рассказали. Хоть где-то можно элементарно узнать теорию о jwt
да она повсюду
Я правильно понял, что 1RT = много AT?
И вообще я практикую сейчас архитектуру, где RT - это JWT c AT. Когда срок AT приходит к концу, то с помощью RT запрашивается новая пара AT и RT, старые AT (инфу о том, что именно он просрочился я беру из RT) и RT помечаются как отозванные. Т.е 1RT = 1 новый RT = 1 AT.
я так понимаю что AT обновляется с помощью RT, RT может обновляться в этот момент (продлеваться), получается что RT должен храниться на стороне сервера, интересно, если будут миллионы запросов, к разным сервисам (если это микросервисная архитектура), то какие есть возможности оптимизации процесса обновления AT и RT, AT обычно имеет короткий срок жизни, поэтому запросов на обновление AT может быть очень много, если к серверу подключено большое количество сессий
подскажите, как отдельный микросервис проверяет валидность access токена?
по идее сервис должен знать секрет. Когда присылаем ему payload + signature, сервис берем payload и с помощью секрета подписывает его и получает свою signature. Если переданная и рассчитанная signature совпадают, то значит токен валиден
@@ilyakushlianski6519 Секрет нужен для шифрования токена. А для валидации публичный ключ. Вот им уже можно делиться с другими приложениями.
@@MrLotrus публичный ключ это один из вариантов
Мысли, конечно, интересные и, вероятно, оригинальные. Но вы сами напросились на вопросы :)
1.Есть масса уже принятых и проверенных стандартов(протоколов) с использованием JWT. Не исключено, что вы предлагаете ещё лучше. Но чтобы это понять надо увидеть сравнение с существующими. Или я пропустил?
2.В как минимум одном из стандартов освежающий жетон(refresh token) используется только один раз для получения новой пары жетонов. И это даёт возможность быстро обнаружить его повторное использование, в отличие от предлагаемого вами многократного использования refresh token. Почему вы не используете это известное решение?
3.По поводу поддержки сессии:
3.1.Вы связываете освежающий жетон(refresh token) с сессией в приложении?
3.2.Если да, то как передаёте эту информацию в приложение?
3.3.Если заново установили подлинность(authenticate) и получили новый освежающий жетон(refresh token) то считаете началась новая сессия в приложении?
Где Ночное Видео??????
Про Монолитныую Архетиктуру....и.п......
Чуть осталось Досмотреть!!!!
а при первом запросе пара логин и пароль не шифруется? А если шифруется, то как сервер понимает как это нужно расшифровать?
А смысл, если всё передаётся по https
Как SERVICE поймет что AT действительный?
токен подписан подписью, на стороне сервиса должна быть подпись с помощью которой сервис может проверить, что токен валидный
а если при выдаче access_token добавлять в него ip клиента и проверять в сервисах ip из запроса с тем что лежит в jwt? По идее это же добавит безопасности, но не решает проблему целиком. В таком случае, если у нас в сервис придет не тот адрес мы можем послать сообщение на инвалидацию RT и перелогин пользователя.
Вероятно, что в таком случае токен будет инвалидироваться слишком часто в мобильных устройствах
В видео не рассмотрен вопрос как вход/доступ с нескольких устройств (рабочий комп/домашний/ноут) или смартфона, те ip постоянно меняется, те надо делать коллекцию RT пользователя, где-то хранить, проверять "протухшие" и тп и тд, так что возни много
Знает кто нибудь статью или гайд как реализовать подобную архитектуру на spring boot?
А что вы скажете про такую архитектуру. Насколько она безопасна. При регистрации, авторизации сервер выдает согласно логину и пароль закодированнный сигнатурой ключевого слова токен. Дальше токен на клиенте хранится в локалсторидже. Далее при каждом запросе в интерсепторах или мидлвере в заголовке мы кладем токен закодированный. А на стороне сервера перед доступом к сервисам роутов мы делаем проверку гуардс во фрейморке на токен парсим его и проверяем в БД есть ли такой пользователь с таким логином и паролем, и дальше даем доступ к апи. Тут смысл в этом что токен один.
Теряется смысл использования JWT, если при каждом запросе надо лезть в БД.
@@MrLotrusВсмысле? Так в токене лежит к примеру userId, мы отправляем запрос на получение к примеру постов пользователя, в запросе отправляем токен, на сервере в данных с jwt получаем userId и по этому айди ищем посты у которых userId автора совпадает с userId который пришёл в запросе. О каком смысле jwt с бд ты говоришь?
@@sochilling у тя уже есть подпись токена, которая на стороне сервера делается, просто клади в payload доп инфу, типа ролей
А как пользователь получает secret?
Если имеется ввиду клиент, то никак.
Передача refresh token на клиенскую сторону плохая идея, потому что в случае его утечки, третье лицо сможет пользоваться им бесконечно, отозвать будет очень сложно и не быстро.
Нужно делать чёрные или белые списки рефреш токенов в базе и во время каждого рефреша проверять по наличию в базе. Так же в профиле/аккаунте пользователя нужно сделать кнопку "Выйти на других устройствах", которая инвалидирует остальные токены этого пользователя из белого списка.
@@username-forbidden доп списки доп нагрузки
так и не сказал что использовать вместо jwt там где его нельзя использовать...
Сессии
А что если мы будем хранить в рефреш токене ip адрес и девайс, с которого произошёл логин, и шифровать этот токен. Далее представим злоумышленник украл рефреш токен и пытается получить новый рефреш токен. Об cодержание токена, то есть об ip адресе и девайсе ему ничего не известно в силу того, что токен - это какая-та зашифрованная строка. Мы получаем от него украденный рефреш токен, дешифруем его, сверяем айпи адрес и девайс запроса с соответствующими значениями в токене, если проверка не прошла, то отклоняем запрос, иначе, то есть запрос на новый рефреш токен делает исходный юзер, что и получил изначальный рефреш токен, тогда выдаём новый рефреш токен. Какие подводные камни у такой схемы?
Возможны, ситуации как я понимаю, когда ip может меняться слишком часто. Например, в случае мобильной связи
Злоумышленник все знает о ip и девайсе.
Шифруется только secret,
Payload просто использует HS256 или что-то еще.
Со склейками, правками и редактурой.
Что
@@K392-f4k
Видос.
Какое-то лицо сглаженное и осветлённое, смотрится как-то не оч