JWT-аутентификация для нативных приложений - Spring Security
HTML-код
- Опубликовано: 2 июл 2023
- JWT-аутентификация - это токен-аутентификация с использованием ключей доступа сериализованных в формате JWT - JSON Web Token.
В этом ролике я продемонстрирую реализацию получения и обновления ключей доступа, аутентификации при их помощи, а так же блокировку ключей.
Репозиторий проекта: github.com/alex-kosarev/sprin...
#java #jwt #springsecurity
Мой сайт: alexkosarev.name/
Паблик в VK: public218833461
Канал в Telegram: t.me/+TZCuO38vG3oqu_Jq
Стать доном: donut/shurik.codes
Донаты в Boosty: boosty.to/akosarev/purchase/1...
Донаты в Tinkoff: www.tinkoff.ru/cf/4PEOiVCZQuS
Огромное спасибо за твой труд! Не смотря на то, что уроки действительно получаются долгими и к концу в голове каша из фильтров и токенов, я бы с удовольствием потратил ещё 10-15 минут на просмотр "разбора полётов" по материалу. Хотелось бы услышать хотя бы вкраце что для чего нужно и алгоритм взаимодействия всего этого между собой. Ещё раз спасибо!!
Здравствуйте! Пожалуйста не переживайте по поводу времени ролика, тема большая и сложная, было очень интересно.
Три и дня (без "и три ночи :D") разбирался что к чему, подходя к теме без углубленных знаний Spring Security (максимум, знал про контекст безопасности, роутинг и какие-то дефолтные настройки, да и всё касается секьюрности через сессии, а не токены), без фундаментальных знаний о JWT, но всё-таки всё получилось, благодаря Вам) Очень много различных статей на тему jwt, в которых или суть до конца не раскрывается и непонятно как работать, или делается грязно и неправильно с учетом той же секьюрности.
Было сложно, интересно, местами непонятно и запутанно (к середине я уже перестал понимать, где я, кто я и что за что отвечает и как коммуницирует друг с другом), но в конце, просмотрев все классы по порядку, опираясь на конфигурер, стало гораздо понятнее) Спасибо большое, очень понравилось объяснение и разъянение, слушать приятно, очень жаль, что не наткнулся на канал раньше) Присмотрел для себя много тем, в которые хотелось бы углубиться)
Очень круто, спасибо!
ОГРОМНОЕ СПАСИБО за ролик, очень помог!)
Спасибо большое информации много сразу не все понял, но лучше объяснить невозможно. Спасибо за возможность посмотреть код потому что пересматривать буду точно.
Спасибо за видео!
Комментарий в поддержку канала. Так держать.
Очень годно!👏
Какой же ты красавчик!
Это, пожалуй, самое лучшее видео из вообще всех, что я видел по части реализации JWT-авторизации. Было бы круто, если бы было показано как и /login закастомайзить вместо использования стандартной бейсик-аутентификации, но концептуально это и так понятно как сделать. Вы - огонь! Спасибо!
Про аутентификацию при помощи формы есть в следующем видео)
@@shurik_codes посмотрю, спасибо! Есть в планах аутентификация с помощью нескольких провайдеров? Например, в базе через jdbc, а если не вышло, через *** (например, ldap).
Так это делается при помощи нескольких вызовов метода authenticationProvider() у HttpSecurity) Можно сколько угодно провайдеров добавить таким образом. Отдельно ролика с демонстрацией этого, возможно, не будет, но будет ролик, посвящённый детальной настройке цепочки фильтров безопасности.
@@shurik_codes супер!
Контент огонь 👍 но роликов типо образного понимания много, а как правильно делать мало кто показывает. Лично мое мнение, что те кто в курсах вскользь может и глянут, а тем кто учиться вот как раз не будет хватать той инфы.
Бомба пушка просто
Спасибо за то что делаете ролики по спрингу, на русскоязычном ютубе актуальных и одновременно качественных материалов как у вас достаточно мало. Еще вопрос, вы сказали что не используете lombok на практике, есть ли какие либо минусы в его использовании, из за которых им лучше пренебречь, или это лишь вопрос предпочтений?
В большей степени это вопрос предпочтений
А я бы не против и хоть 10-ти часовой ролик смотреть. Я к тому, ты говоришь, что если делать все правильно с точки зрения архитектуры, то ролик будет дольше по времени. В любом случае спасибо за труд и за то что делишься!
Спасибо за ролик! В самом начале была оговорка про большое количество примеров где аутентификация делается через контроллер (в нем ИМХО как будто бы ощущается бОльший контроль над ситуацией), но так действительно выглядит каноничнее) Но тут появился такой вопрос - что делать, если у нас например аутентификация двухфакторная? Допустим, при получении логина-пароля мы генерим код, идем в редис и складываем ТОТР, который ожидаем в следующем запросе, на который уже и возвращаем токены. С контроллером как будто бы понятно как это сделать, а как быть без него?
Есть два варианта реализации:
1. Передавать второй пароль в одном запросе с логином и основным паролем. Это потребует изменения в фильтре аутентификации, новой реализации Authentication и AuthenticationProvider
2. Если хочется всё же передавать второй фактор отдельным запросом, то потребуются два дополнительных фильтра: первый будет проверять подтверждённость второго фактора (в файлах куки, сессии и т.д.) и при её отсутствии перенаправлять на страницу ввода второго фактора, второй будет уже запускать проверку второго фактора при отправке запроса из формы ввода второго фактора.
Кстати, сохранять одноразовый пароль в редис нет смысла, вычисление пароля не такая уж и ресурсоёмкая операция.
Ролик про двухфакторную аутентификацию будет.
@@shurik_codes спасибо!
Привет! Огромное спасибо за видео, очень круто, очень мало русскоязычного материала в таком качестве. Подскажи пожалуйста, данный способ реализации ведь не подходит для реактивщины ? Будет ли видео с разбором реализации аутентификации и авторизации в WebFlux ?
Да, демонстрируется вариант для приложений на основе Servlet API, для реактивщины ролики ещё впереди
Спасибо за классное видео! Хотелось узнать, почему выбор пал на использование nimbus jose jwt ? В Spring есть Spring Authorization Server (раньше был Spring Security OAuth). По мне лучше использовать spring стек, а если есть проблемы, то только тогда переходить на сторонние библиотеки. Может есть какие-то проблемы с Spring Authorization Server ?
В данном ролике демонстрируется аутентификация при помощи JWT-токенов в чистом виде, вне контекста OAuth/OIDC, поэтому не Spring Authorization Server.
Добрый день, после просмотра видео появилось несколько вопросов:
1. В каких случаях может использоваться logout? Как я понял, запрос на логаут отправляется со стороны клиента после выполнения refresh для удаления старых токенов. Исходя из других источников, в случае обновления токенов, возвращается как access, так и refresh, поэтому старый refresh токен должен перестать функционировать.
2. В некоторых полях вы указывали стандартную реализацию как Object::toString. Что именно будет происходить, если не присвоить такой переменной другой объект?
1. В моей логике refresh-токен может выдать только новый access-токен, но не refresh. Тем не менее, JTI у всех их должен быть один, и по нему должна быть возможность заблокировать все токены разом на случай, если какой-то токен был скомпроментирован.
2. Просто возвращает обычное строковое представление
Огромное спасибо!@@shurik_codes
Здравствуйте. Прежде всего большое спасибо за отличное видео.a у меня есть вопрос. я отправил запрос к API "/manager.html" с токеном "Bearer". и это сработало. Но это сработало, даже если я сделал запрос к этому API с токеном «Basic». Должны ли мы исправить эту часть самостоятельно? или я что-то пропустил? Я думаю, что «BasicAuthenticationFilter» делает это.
В целом в таком проведении нет ничего страшного, но если есть желание жёстко требовать аутентификацию по помощи токена, то да, это можно сделать несколькими способами. Например, Basic-аутентификацию вынести в отдельную цепочку фильтров безопасности или в права пользователя внести признак аутентифицированности по токену, а затем проверять доступ по нему
Спасибо, видео очень крутое получилось, ты точно не зря старался
Думаю, что люди будут даже через много времени будут обраться к этому видео
Подскажи пожалуйста, keycloak как я понимаю в мое приложение отправляет jwtToken, и из него строиться Authentication, как вмешаться в этот процесс создания ? Чтобы допустим изменить что-нибудь
Я подумал, что это что-то похожее на твой UserDetailsService, но не уверен
В ролике про Keycloak я упоминал JwtAuthenticationConverter, этот класс можно расширить и изменить логику преобразования Jwt в AbstractAuthenticationToken (это для ресурс-сервера). Впрочем, исходный JWT всегда доступен через JwtAuthenticationToken.getPrincipal().
Для OAuth-логина логику можно изменять, например, в OAuth2UserService, что я тоже показывал в том же ролике.
@@shurik_codes спасибо
Привет, а я бы хотел уточнить, получается сначала юзер получает userpass аутентификацию, которая даёт получить токены, но каким образом дальше такой тип аутентификации перекрывается pre authenticated токеном?
Basic-аутентификация игнорируется при использовании JWT, т.к. на момент получения запроса фильтром Basic-аутентификации пользователь уже аутентифицирован, т.к. фильтр JWT-аутентификации в цепочке фильтров безопасности располагается перед фильтром Basic-аутентификации
Можно вопрос? Как можно было бы сделать: я реализую resource server (перехожу со старой версии где сервер через наследование ResourceServerAdapter). Для проверки подписи я использую публичный ключ с auth сервера /oauth/token_key. Но он возвращает json {"alg": "", "value": "публичный ключ в формате PEM"}. Стандартная история с jwk-set-uri параметром в конфиге, где по идее должны возвращаться данные по публичному ключу, ругается что у меня в /oauth/token_key нет keys=). Json не содержит обязательных полей Есть ли стандартные решения этой проблемы (какой-нибуть декодер или провайдер для переопределения)? Если возможность не городить велосипеды ?)))
Вот сходу не скажу, надо смотреть, но обычно есть точки внедрения
@@shurik_codes По идее они должны быть ( но пока не нашел
Можешь скинуть стек-трейс в Telegram или в VK?
передавать authorities/permission в jwt токене это стандартная практика? т.к. их может быть 100 или 200 шт. и в этом слуае размер jwt токена сильно увеличится или это норм?
Вполне стандартная практика, но если полномочий/ролей сильно много, то в сервисе авторизации нужно предоставлять отдельный эндпоинт для получения списка полномочий пользователя, аналогично userinfo-эндпоинту из OIDC.
Доброго времени суток! А почему на практике не пользуетесь Lombok-ом если не секрет))?
@Data мне заменили record, остальное не особо актуально для меня
@@shurik_codes Для видеоуроков Lombok самое то. Можно часть конструкторов, геттеров с сеттерами и логгеры убрать. А то куче текста сложней сориентироваться.
1. 1:07:32 Вопрос, а почему надо давать роли для refresh-а token-а, почему бы не сделать чтобы все могли делать refresh? (и тоже самое с JWT_LOGOUT, почему для этих действии нужны роли)
2. Почему ты не сгенерировал новый refresh token?
3. Почему ты не используешь JPA?
4. Почему ты добавляешь свои кастомные фильтры после ExceptionTranslationFilter или ты просто первый попавшийся на ум фильтр вбил?
1. Чтобы только refresh-токены могли управлять сессией. Refresh-токены долгоживущие. Они используются реже, чем access-токены, и их (теоретически) сложнее скомпроментировать. Если access-токены будут иметь возможность продлевать сессию, то это может быть потенциальной уязвимостью.
2. Забыл
3. Потому что на практике редко его использую
4. Чтобы ExceptionTranslationFilter мог обрабатывать исключения
@@shurik_codes а JPA чем хуже? медленнее?
Добрый день! Возник вопрос, откуда берутся access-token-key и refresh-token-key в application.yml? Где они генерируются или по какому алгоритму?
Я их сгенерировал при помощи OctetSequenceKeyGenerator из JOSE-JWT
@@shurik_codesспасибо большое!
Почему использовать substring правильнее, чем replace?
Используется меньше ресурсов:
substring - вычисляется длина текущей строки и целевой подстроки и создаётся новый массив, содержащий байты новой строки
replace - вычисляется длина текущей, заменяемой и заменяющей строк, производится поиск позиций всех заменяемых подстрок в текущей строке, вычисляется размер итоговой строки, создаётся массив байтов итоговой строки, выполняется итеративное копирование символов из текущей строки в массив байт итоговой строки, создаётся итоговая строка
У меня вопрос про эту строку в RequestJwtTokensFilter:
if (this.securityContextRepository.containsContext(request))
То есть получается что request должен содержать в себе контекст безопасности как атрибут.
Но откуда он там берется? Кто его устанавливает? Где ранее происходит request.setAttribute() ?
Вообще не очень понятен этот момент.
Ранее BasicAuthenticationFilter положил контекст безопасности в SecurityContextHolder.
А как код в фильтре его достает?
Контекст безопасности появляется на ранних этапах обработки запроса, а информация о пользователе в контексте появляется при обработке запроса фильтром аутентификации.
@@shurik_codes Спасибо. А почему используется именно RequestAttributeSecurityContextRepository? Можно же использовать context = SecurityContextHolder.getContext() вместо context = this.securityContextRepository.loadDeferredContext(request).get() и все будет работать. Ну у меня по крайней мере работает )
Добрый день. Такое ощущение, что я пропускаю момент в видео получения токена при первичной ацтентификации. Т.е. когда пользователь вводит пароль и логин а в ответ получает токены. Может я непраивльно понимаю как должен протекать весь процесс работы через токены? 1.Пользовательский ввод пароля и логина. 2,В ответ получение токена. 3,Сохранение его на клиенте. 4,Дальнейшие запросы через это токен. Подскажите, плиз
38:22
@@shurik_codes от души :)
а как ты делаешь post request на /jwt/tokens, я имею ввиду откуда ты взял этот токен в Authroization: Basic {token}??
Не совсем понял вопроса. Данный запрос обрабатывается фильтром RequestJwtTokensFilter, используется Basic-аутентификация, в которой токен - это Base64-кодированная строка, содержащая логин и пароль пользователя
@@shurik_codes 38:33 к примеру здесь, я здесь вижу только POST request с header-ом Authorization Basic {и какой-то токен (откуда этот токен?)}, я просто запутался и не понимаю как авторизоваться
Логин/пароль можно подсмотреть в этом файле: github.com/alex-kosarev/spring-security-jwt/blob/main/src/main/resources/data.sql
Токен, как я уже сказал, при Basic-аутентификации, вычисляется при помощи кодирования логина и пароля в формате Base64:
Base64.getEncoder().encodeToString("j.jameson:password".getBytes(StandardCharsets.UTF_8)), получается ai5qYW1lc29uOnBhc3N3b3Jk
в JS это можно сделать при помощи функции btoa("j.jameson:password"), например, ну или любым онлайн-сервисом
@@shurik_codes понял спасибо большое, а можно узнать почему именно таким способом?
@@tami-he4mm стандартный способ аутентификации при помощи логина/пароля
Дамблдор 🧙♂, ты ли это?) Для работы на джуна я должен это всё так же знать?
Отнюдь, для джуна [бекенд-разработки] на мой взгляд достаточно знать Java (Kotlin, Groovy, нужное подчеркнуть), принципы ООП, базовые структуры данных и алгоритмы, SQL и базово какой-нибудь фреймворк: Spring, Jakarta EE, Quarkus, Micronaut, Helidon. Не глубоко, но достаточно, чтобы написать простое приложение.
@@shurik_codes получается в портфолио с проектами не нужно заморачиватся с добавлением spring security? Без образцов написанного кода резюме как понимаю вообще пропускают и шлют отказы.
Это всё великолепно. И я выражаю Вам огромную благодарность за вашу работу. Но я не могу взять в толк: для Rest приложения подобная аутентификация применима или нет? если да, то как?
Получить ключи доступа при помощи RequestJwtTokens, в дальнейших запросах передавать ключ доступа в заголовке Authorizatin: Bearer ...
@@shurik_codes Возможно глупо говорить что у Вас нет такого класса, но я честно не понимаю из чего мне получить что-то типа authenticateAndGenerateTokens(login, password) в своём рест контроллере. Я так понимаю что этим занимется TokenAuthenticationClientDetailsService и он возвращает public UserDetails loadUserDetails(PreAuthenticatedAuthenticationToken authenticationToken) и дальше я в тупике...
@@shurik_codes
POST localhost:8080/jwt/tokens
Authorization: Basic пожалуйста прокомментируйте что тут за набор символов на минуте 38:42
В первом запросе для получения токенов - Basic-аутентификация с логином/паролем в Base64, в ответ приходит JSON содержащий в себе ключи доступа. Второй запрос уже демонстрирует Bearer-аутентификацию с ключом доступа
@@shurik_codes Спасибо
А как у вас удаляются заблокированные просроченные токены из БД, чтобы они не скапливались?
Это несложно реализовать при помощи заданий по расписанию (@Scheduled)
28:54 мы выбрасываем ошибку AccessDeniedExeption() А при каких обстоятельсвах она выбрасывается? Просто если неправильные пароль и имя, у меня в фильтр даже не заходит и сразу выдается ошибка 40. При правильной паре имя пароль выдается токен. В другом случае выполняется цепочка фильтров дальше. А как вызвать ошибку из фильтра?
Если в запросе не передавать заголовок Authorization, то будет.
@@poleg75 спасибо. попробую
Неужели нельзя все это сконфигурировать в application.yml и не писать столько кода?
Чтобы что-то сконфигурировать в application.yml, нужно чтобы это что-то было
Интересно, но ОЧЕНЬ замороженная схема получается. Действительно ли это необходимо
А в чём конкретно замороченная?
@@shurik_codes в создании сериализаторов, десериализаторов, фабрик по созданию токенов. Насколько это все необходимо не ясно, есть же гораздо проще библиотеки. Но да, там не будет энкрипт токен, но для какого уровня сервиса нужны такие токены?
Если рассматривать сериализаторы, десериализаторы и фабрики чисто с точки зрения ролика, то да, они усложняют материал и увеличивают количество информации. А вот с практической точки зрения они нужны, чтобы итоговая архитектура получилась гибкой и допускала иные способы создания, сериализации и десериализации токенов.
Здравствуйте, а как сделать HTTPS соединение Мобильного приложения и Сервера, чтобы хакер не смог реверснуть Мобильный клиент и получить ключи шифрования?
Не было идеи запизать видос по тестам с спринг секьюрити?
Возможно, стоит записать
@@shurik_codes Да стоит. Поверхностной информации в ютубе много. А у вас все более углубленно. А с поверхностными знаниями к сожалению трудно в IT пробиться. Кроме того у вас самая актуальная информация в русскоязычном варианте.
я сперва ничего не понял, а потом кааак понял.
Спорный ролик. С одной стороны видно что подход отличается от того что у большинства видео по запросу "SpringBoot JWT" и производных, а с другой стороны возникает вопрос: "Для кого это видео?" Для новичков в Spring Boot появляется больше вопросов чем ответов. Для тех кто в теме это не нужно. Остается только вывод, что тут было показанно экспресс программирование. Пойду наверное ChatGPT опрашивать.
Вместо того чтобы перезаписывать видеоролики из-за того что они долгие, почему просто не смонтируешь?
а я так теперь и делаю
Очень сложный туториал, очень много чего не сказано, скорее всего из-за - ну это итак должно быть понятно. Приходится разбираться, копаться, с одной стороны полезно, с другой стороны, хотелось бы услышать больше комментариев, так как личные изыскания могут быть неверными.
Лично я 18 минут ролика 3 рабочих дня изучал. Но может это моя такая пришибленность - хочется видеть всю картину в целом, чтобы было проще изменять частности.
Даже вопросы типа: "а почему именно jose, а не другая библиотека?" требуют комментариев.