Spring приложение сервера авторизации oauth 2 использует один и тот же контекст безопасности с другим приложением

У меня есть два приложения сервера авторизации ( spring boot 2.0.5).

Два приложения сервера авторизации похожи

Когда пользователь запрашивает токен, Spring зарегистрирует сеанс для этого конкретного пользователя и вернет токен. strong>токен, с помощью которого вы можете получить доступ к ресурсу приложения 1, но вы не можете получить доступ к ресурсу приложения 2.

Мой вопрос заключается в том, есть ли способ совместно использовать один и тот же контекст безопасности, кроме того, когда вы создаете токен из приложения 1, который вы можете использовать для доступа к ресурсу приложения 2.


spring-boot spring spring-security spring-security-oauth2
person Djamel Kr    schedule 23.10.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Что вы можете сделать, так это сделать ваши приложения без состояния, когда дело доходит до безопасности.

Что это значит?

Spring Security больше не будет создавать сеанс для нового вошедшего в систему пользователя. Когда пользователь входит в систему, вы выдаете ему токен (например, JWT). Каждый раз, когда пользователь получает доступ к защищенному содержимому, он/она должен будет предоставить токен, и ваши приложения будут проверять этот токен с помощью открытого или закрытого ключа (в зависимости от того, какой тип шифрования токена вы будете использовать — симметричный или асимметричный). В конце концов, вам не нужно будет ничем делиться, если оба ваших приложения имеют одинаковые ключи для проверки входящих токенов.

Несколько советов:

Маркер, который вы отправляете при каждом запросе на доступ к защищенным ресурсам, называется «токен доступа». Сделайте его сроком действия и сделайте его недолгим (например, 15 минут). Почему? Этот токен не может быть немедленно аннулирован, в отличие от сеанса, который можно просто удалить. В случае, если кто-то его угонит, он все равно сможет получить доступ к защищенным ресурсам.

Поскольку ваш «токен доступа» недолговечен, пользователю будет неудобно входить в систему каждые 15 минут. Чтобы продлить его жизнь, вы можете иметь другой тип токена, называемый «токен обновления», который можно хранить в какой-либо базе данных. Этот токен можно немедленно аннулировать, просто удалив его из базы данных. Поэтому, если кто-то даже его угонит, пользователь сможет отозвать его, а угонщик не сможет продлить свою сессию.

Ссылки: Аутентификация без сохранения состояния с помощью JWT

person Branislav Lazic    schedule 23.10.2018
comment
@BranislavLazic Спасибо за ваш ответ, может быть, я плохо объяснил, у меня есть несколько (3 экземпляра) приложения сервера авторизации, которые используют токен доступа с балансировкой нагрузки (Ribbo), поэтому, когда пользователь входит в первый экземпляр, а затем экземпляр 1 будет отключена лента переключится на экземпляр 2, в этот момент нам не нужно, чтобы клиент снова выполнял аутентификацию !! - person Djamel Kr; 23.10.2018
comment
@KrDjamel Ага. Я прекрасно знаю об этом. Не имея никакого состояния (сеанса) в вашем приложении, вам не нужно беспокоиться о том, какое из них будет затронуто балансировщиком нагрузки. - person Branislav Lazic; 23.10.2018

arrow_upward
0
arrow_downward

Мы тоже сталкиваемся с подобной проблемой. Для веб-страниц мы используем SSO, который кэширует токен в clientContext и использует Authorization-server-1.

Для вызова API-1 мы используем токен, сгенерированный Authorization-server-2. В этом случае мы создали еще один сессионный компонент для clientContext, и это кэширующий токен (имеющий собственные oauth2RestTemplate и clientCredientialResource). это можно сделать, поскольку получение токена доступа представляет собой двухэтапный процесс (с использованием кода авторизации), а обратный вызов снова выполнит весь метод, а не продолжится со строки после вызова для отдыха API.

person Amit Gadkari    schedule 25.10.2018