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

Question

У меня два приложения сервера авторизации ( пружинная загрузка 2.0.5 ).

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Некоторые советы:

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

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

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