JWT and Spring Security - Weekly Tips #18 (#livecoding #springframework #springboot)

• Александр Бармин рассказывает о выпуске по Spring Security.  

• Видео будет длинным и интересным, с обсуждением JWT токенов и криптографии.  

• Призывает подписываться, комментировать и поддерживать канал.  

• Обсуждение работы с сервером ресурсов и JWT токенов.  

• Вспоминание предыдущих выпусков и добавление возможности входа через Google.  

• Упоминание двух Security Filter Chains для веб и REST.  

• Выключение CSRF для REST запросов.  

• Добавление зависимости для Spring Boot Starter Resource Server.  

• Объяснение, что такое Resource Server и его роль в управлении доступом к ресурсам.  

• Переход к конфигурации Security Configuration.  

• Приложение не запускается из-за наличия двух Security Filter Chains.  

• Добавление JWT декодера для работы с Resource Server.  

• Создание и настройка JWT декодера.  

• Приложение снова не запускается из-за отсутствия JWT декодера.  

• Объяснение роли JWT декодера в конвертации токенов в объекты.  

• Обсуждение JWT аутентификации и провайдера.  

• Отправка запроса без JWT приводит к ошибке 401 Unauthorized.  

• Объяснение работы JWT аутентификации через фильтр.  

• Проверка JWT токенов через фильтр.  

• Фильтр проверяет наличие и правильность JWT токенов.  

• Объяснение, как фильтр обрабатывает запросы с JWT токенами.  

• Проблемы с неправильными JWT токенами.  

• Фильтр не может найти JWT токен и выдает ошибку.  

• Переход к следующему способу аутентификации через форму логина и пароля.  

• JWT расшифровывается как JSON Web Token.  

• JWT состоит из трех частей: заголовок, тело и подпись.  

• JWT используется для передачи данных между клиентом и сервером.  

• Стейтфол аутентификация хранит информацию о пользователе на сервере.  

• Стейтс аутентификация не хранит информацию о пользователе, а прикрепляет её к каждому запросу.  

• Стейтс аутентификация используется в микросервисной архитектуре.  

• JWT состоит из заголовка, тела и подписи.  

• Заголовок и тело обязательны, подпись необязательна.  

• Для генерации JWT используются зависимости: Джексон и Base64Encoder.  

• Простой JWT не имеет подписи.  

• Для генерации используется Джексон и Base64Encoder.  

• Заголовок содержит тип и алгоритм JWT.  

• Тело JWT обычно содержит данные о клиенте.  

• Поле "sub" идентифицирует клиента.  

• Тело JWT конвертируется в JSON и кодируется в Base64.  

• Простой JWT проверяется на валидность.  

• JWT передается в приложение для аутентификации.  

• Приложение использует провайдер для проверки JWT.  

• Для работы с JWT используется класс Jwt из библиотеки Nimbus.  

• Создается адаптер для конвертации между JWT и Spring.  

• Адаптер добавляет необходимые поля в JWT для корректной работы.  

• Создание адаптера для преобразования токенов.  

• Отправка запроса и проверка работы через Postman.  

• Завершение работы с токенами.  

• Возможность генерации токенов стандартными средствами Java.  

• Создание плейн хедера и токена с помощью Jettison.  

• Сериализация токена в строку и проверка работы через Postman.  

• Разграничение доступа в токенах.  

• Использование скопов для доступа по ролям.  

• Аутентификация через JWAuthenticator.  

• Конвертация токенов в абстрактные аутентификационные токены.  

• Извлечение авторити из токенов.  

• Конвертация авторити в грант авторити.  

• Несовместимость между авторити в приложении и веб-интерфейсе.  

• Переопределение JWAuthenticator для корректной работы.  

• Создание кастомного конвертера для маппинга авторити.  

• Использование подписанных токенов для защиты.  

• Генерация ключей для асимметричной криптографии.  

• Сохранение ключей в файлах и использование их в приложении.  

• Создание кастомного JWDecoder для работы с подписанными токенами.  

• Использование Nimbus JWDecoder для декодирования токенов.  

• Завершение работы с подписанными токенами.  

• Приложение запускается и работает нормально.  

• Запрос перехватывается фильтром аутентификации и передается в провайдер.  

• Джод декодер проверяет тип токена и генерирует подписанный токен.  

• Создается хедер токена с использованием алгоритма RSA-256.  

• Хедер токена состоит из двух частей: заголовка и тела.  

• Для генерации подписанного токена требуется класс RSASigner.  

• RSASigner принимает приватный ключ для подписи.  

• Подписанный токен состоит из заголовка, тела и подписи.  

• Проверка токена и его подписывание происходят в методе sign.  

• Проверка правильности состояния токена и поддерживаемого алгоритма.  

• Подписание токена происходит с использованием метода sign.  

• Подписываются две части токена: заголовок и тело.  

• Декодер парсит токен, конвертируя его в JSON.  

• Извлекается алгоритм токена, который определяет его тип.  

• Парсинг токена происходит по частям: заголовок, тело и подпись.  

• Декодер создает объект из трех частей токена.  

• Парсинг тела токена происходит быстро, так как тело представлено в формате JSON.  

• Проверка токена необходима для предотвращения подделки.  

• Проверка типа токена и вызов типа вери файер.  

• Использование кей селектора для выбора ключей для проверки подписи.  

• В конкретном случае используется один ключ, так как он хранится в приложении.  

• Создание вери файера из ключа.  

• Проверка подписи токена и конвертация в Base64.  

• Убедившись в правильности токена, конвертируем его в JWT.  

• Использование подписанных токенов для устранения уязвимости.  

• Добавление дополнительного клейма для ограничения срока действия токена.  

• Проверка токена на валидность и истечение срока действия.  

• Генерация зашифрованного токена с использованием алгоритма AES-256-CBC.  

• Создание и сохранение ключа шифрования.  

• Настройка декодера для работы с зашифрованным токеном.  

• Приложение не может обработать подписанный токен, так как настроен валидатор для зашифрованных токенов.  

• Необходимо сгенерировать зашифрованный токен.  

• Используются те же ключи и хедер, что и для подписанного токена.  

• Создается живой хедер с параметрами алгоритма и метода шифрования.  

• Зашифрованный токен создается с помощью AES-инкриптора.  

• Зашифрованный токен отправляется в Postman для проверки.  

• Парсер распарсил токен, но пойло еще не доступно.  

• Для расшифровки используется ключ, выбранный из кандидатов.  

• Ключ выбирается с помощью живого кей селектора.  

• Создается декриптор для расшифровки зашифрованного токена.  

• Происходит проверка и валидация токена.  

• Информация из токена доступна в объекте аутентификации.  

• В следующем видео будет обсуждаться проблема распространения ключей.  

• Призыв подписаться на канал и оставлять комментарии.