Client, Resource Server, Login - Spring Security OAuth 2.0
Vložit
- čas přidán 22. 08. 2024
- В одном из предыдущих роликов я рассказал теорию об OAuth 2.0 и OIDC, а на этот раз предлагаю перейти к практике. Spring Security реализует практически полноценную поддержку протокола авторизации OAuth 2.0 и его расширения аутентификации OpenID Connect (OIDC), и с минимальными изменениями в своём проекте вы можете внедрить поддержку этих протоколов. В этом ролике я рассматриваю возможность применения Spring Security OAuth 2.0 для реализации сервера ресурсов, клиента и логина в веб-приложениях на основе Spring WebMVC и Spring Webflux. Так же в качестве сервера авторизации снова будет рассмотрен Keycloak, а так же процесс его настройки.
Репозиторий проекта: github.com/ale...
Ролик про OAuth: • Основы OAuth 2.0 и Ope...
00:00:44 Запуск и настройка Keycloak
00:08:18 Сервер ресурсов (WebMVC)
00:25:15 Сервер ресурсов (Webflux)
00:32:10 Клиент и логин (WebMVC)
01:02:37 Клиент и логин (Webflux)
#java #spring #security #oauth #oidc #reactive #webflux #webmvc
Обсудить в Telegram: t.me/+UFAkw187...
Мой сайт: alexkosarev.name/
Паблик в VK: public2...
Канал в Telegram: t.me/+TZCuO38v...
Стать доном: donut/s...
Донаты в Boosty: boosty.to/akos...
Донаты в Tinkoff: www.tinkoff.ru...
Супер урок, впервые попал на канал, ощущение, что нашел золото в интернете xD Теперь я понял, что надо и другие ролики посмотреть
Офигеть какой полезный контент по такой тяжелой теме. Придется пересматривать не один раз, чтобы так же быстро все понимать. Отдельное спасибо за демонстрацию для реактива!
Не смотрел. Просто лайк за труд.
Сейчас уже начну смотреть 😊
Спасибо большое за качественно изложенный материал и Ваш труд
Лайк сразу. Имею пару лет коммерческого опыта, но смотря ваши видео понимаю, что я очень многого не знаю и как минимум на вашем канале есть огромное пространство для саморазвития, это круто. Спасибо ))
Нравится звук клавиатуры, слышно работу поограммиста!
Мега полезный материал! Нереально крутой спец и видео подготовлено великолепно. Спасибо! Попробую разобраться, почему в реактивном варианте не настраивается проверка как скоупа, так и роли)
Да настраивается она там, но там получается очень весёлый порядок действий получается, реактивный) Возможно, я не нашёл нужный компонент
Спасибо большое, ты лучший!)
9:25 - resource
25:12 - reactive resource
32:08 - client
1:02:40 - reactive client
Спасибо за материал! Пересмотрел уже десятки видео на канале. Видео, благодаря качеству материала и подаче, получаются просто бесценными!
Можете подсказать, какие-то отличия в реализации есть, если в роле клиента будет android-приложение?
Нет, отличий не будет, android-приложение будет клиентом без client secret, поэтому желательно использовать grant_type=authorization_code с PKCE.
@shurik_codes Спасибо за фидбек! Буду разбираться. Тогда я бекенд делаю просто защищенным с помощью кейклока, а фронт-приложение делаю клиентом, который будет бегать в кейклок за токеном для юзера
Спасибо за видео!
31:40 stateless session creation policy нужно было ставить?
По идее надо, но в реактивных API это делается при помощи http.securityContextRepository(NoOpServerSecurityContextRepository.getInstance())
Привет, очень полезное видео, спасибо большое
Подскажи пожалуйста, как часто вызывается oidcUserService ? при каждом запросе или нет?
При аутентификации, после - создаётся HTTP-сессия и данные пользователя сохраняются в ней
@@shurik_codes спасибо огромное
Привет, очень просим подробнее про настройку безопасности в Spring Boot и logout в Keycloak'e, ибо при логауте пользователь остается аутентифицированным, как это исправить в интернете не нахожу
Спасибо за видео, а такой вопрос если в связке oauth2(client/server)-jwt надо валидировать токен. к примеру не аунтифицированных отправлять в keycloack не авторизованных на микросервис авторизации и тд как и где это реализовать лучше, хотелось бы библиотеку
Ну, токен и так валидируется, как на стороне клиента (при логине), так и на стороне сервера ресурсов. Перенаправление на страницу авторизации есть при OAuth логине, а на стороне сервера ресурсов в нём нет смысла, т.к. пользователь напрямую не взаимодействует с сервером ресурсов, это делает клиент - приложение или другой сервис.
Спасибо большое за ответ! Сейчас разрабатываем security service никто не сталкивался раньше. И мне сегодня поступила задача сделать библиотеку которая валидирует токен.и хотелось бы ее переиспользовать в других будущих микросервисах. Я так понял в кейклок у нас будет аунтефикация, в ресурсом сервисе авторизация(в процессе еще oauth2 подключать).Видимо (из Вашего ответа) мне надо просто написать клиентскую часть. библиотека которая редиректит если не аунтефицирован или не авторизован или токен протух то иди в автори сервис к примеру. Я так понял отдельный класс с кучей if лучше не делать, сейчас смотрю как раз про Oauth2AutorizedClient Manager --это там можно все сделать?) Сейчас как раз смотрю ваши видео, лучше по security нету следующие про jwt токены буду смотреть.@@shurik_codes
А со спринговым сервером авторизации нет видео, что-то не нашёл?
Пока нет
Спасибо! Такой вопрос: если мы используем Spring Cloud Eureka server, client, gateway - то OAuth2 client куда лучше внедрят front или gateway?
Не совсем понятна схема взаимодействия. Если брать Eureka Server и Client, то Server - OAuth 2.0 Resource Server, а Client - OAuth 2.0 Client
@@shurik_codes тут, вопрос, наверное, о том, где лучше имплементировать oauth2 - на фронте или на gateway
Если честно, то яснее не стало) В OAuth 2.0 предусмотрено две основные роли: клиент (приложение, обращающееся к защищённым ресурсам) и сервер ресурсов (приложение, содержащее защищённые данные). Фронт в моём понимании - это какое-то клиентское приложение (нативное или веб), а шлюз (gateway) - по сути входная точка и маршрутизатор запросов к бекендам.
Можно ли сделать OAuth-клиентом шлюз? В теории - да, можно, если предоставление полномочий реализуется при помощи учётных данных клиента (grant_type=client_credentials). В этой ситуации фронт обращается к шлюзу, шлюз получает ключ доступа и добавляет его в заголовки при маршрутизации запроса к бекенду. Вопрос аутентификации и авторизации клиента остаётся открытым.
Можно ли сделать шлюз сервером ресурсов OAuth? Опять же, да, можно, но на стороне бекендов не будет информации о конечном пользователе, если её только не пробрасывать какими-то окольными путями.
Но оба варианта предполагают внесение изменений в шлюз, что само по себе не совсем удобно - т.к. вариантов тут много (Spring Cloud Gateway, k8s ingress, isio и т.д.)
Наиболее логично на мой взгляд делать фронт OAuth-клиентом, а бекенд - сервером ресурсов, и не включать в схему авторизации шлюз.
@@shurik_codes спасибо, Александр. Буду разбираться.
Привет, каким линуксом пользуешся ?
Linux Mint
Здравствуйте, подскажите пожалуйста. Пытаюсь настроить OAuth2 через Google для аутентификации и регистрации пользователей. В доке написано, чтобы настроить "post-handling of the UserInfo Response", нужно переопределить OidcUserService. В вашем примере вы преобразовали список прав в этом месте.
@Bean
public OAuth2UserService oidcUserService() {}
Правильно ли я понимаю, что я могу в этом же месте добавить логику по регистрации нового пользователя(добавлению в базу данных), извлекая все нужные поля из объекта OidcUser?
В целом можно, да