Client, Resource Server, Login - Spring Security OAuth 2.0  

Да настраивается она там, но там получается очень весёлый порядок действий получается, реактивный) Возможно, я не нашёл нужный компонент

Нет, отличий не будет, android-приложение будет клиентом без client secret, поэтому желательно использовать grant_type=authorization_code с PKCE.

@shurik_codes Спасибо за фидбек! Буду разбираться. Тогда я бекенд делаю просто защищенным с помощью кейклока, а фронт-приложение делаю клиентом, который будет бегать в кейклок за токеном для юзера

По идее надо, но в реактивных API это делается при помощи http.securityContextRepository(NoOpServerSecurityContextRepository.getInstance())

При аутентификации, после - создаётся HTTP-сессия и данные пользователя сохраняются в ней

@@shurik_codes спасибо огромное

Ну, токен и так валидируется, как на стороне клиента (при логине), так и на стороне сервера ресурсов. Перенаправление на страницу авторизации есть при OAuth логине, а на стороне сервера ресурсов в нём нет смысла, т.к. пользователь напрямую не взаимодействует с сервером ресурсов, это делает клиент - приложение или другой сервис.

Спасибо большое за ответ! Сейчас разрабатываем security service никто не сталкивался раньше. И мне сегодня поступила задача сделать библиотеку которая валидирует токен.и хотелось бы ее переиспользовать в других будущих микросервисах. Я так понял в кейклок у нас будет аунтефикация, в ресурсом сервисе авторизация(в процессе еще oauth2 подключать).Видимо (из Вашего ответа) мне надо просто написать клиентскую часть. библиотека которая редиректит если не аунтефицирован или не авторизован или токен протух то иди в автори сервис к примеру. Я так понял отдельный класс с кучей if лучше не делать, сейчас смотрю как раз про Oauth2AutorizedClient Manager --это там можно все сделать?) Сейчас как раз смотрю ваши видео, лучше по security нету следующие про jwt токены буду смотреть.@@shurik_codes

Пока нет

Linux Mint

Не совсем понятна схема взаимодействия. Если брать 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 спасибо, Александр. Буду разбираться.

В целом можно, да