Spring @EnableResourceServer vs @EnableOAuth2Sso

В большинстве обучающих программ, которые я читал до сих пор, используется @EnableOAuth2Sso вместо @EnableResourceServer на шлюзе API. Каковы различия? Что противопоставляет OAuth2Sso?

Детали: Я реализую архитектуру безопасности/инфраструктуры для spring микросервисов и одностраничных приложений. Некоторое время, пока у нас не было требований к безопасности, SPA-центры говорили напрямую с открытыми микросервисами на разных хостах (партия CORS).

Теперь я добавляю уровень безопасности и шаблон шлюза, используя spring-oauth и spring-zuul. Поэтому у меня есть сервис (uaa-service) с @EnableAuthorizationServer и шлюз с @EnableZuulProxy и @EnableResourceServer. Мне нужен только тип предоставления пароля, поэтому у каждого SPA есть собственная форма входа и аутентификация с конечной точкой маркера uaa-сервиса через шлюз, а затем продолжается использование этого токена для дальнейших запросов.

Что-то не так с этим подходом? Должен ли я использовать @EnableOAuth2Sso?

ОТВЕТЫ

Ответ 1

Эти аннотации обозначают ваши сервисы различными OAuth 2.0 ролями.

@EnableResourceServer означает, что ваша служба (с точки зрения OAuth 2.0 - Resource Server) ожидает маркер доступа, чтобы прервать запрос. Маркер доступа должен быть получен с сервера авторизации OAuth 2.0 Client перед вызовом сервера ресурсов.

@EnableOAuth2Sso: отмечает вашу службу как клиента OAuth 2.0. Это означает, что он будет отвечать за перенаправление владельца ресурсов (конечного пользователя) на сервер авторизации, где пользователь должен ввести свои учетные данные. После этого пользователь перенаправляется обратно клиенту с авторизационным кодом (не путайте с кодом доступа). Затем Клиент берет авторизационный код и обменивает его на токен доступа, вызывая сервер авторизации. Только после этого Клиент может позвонить на сервер ресурсов с маркером доступа.

Кроме того, если вы посмотрите на исходный код аннотации @EnableOAuth2Sso, вы увидите две интересные вещи:

  • @EnableOAuth2Client. Здесь ваша услуга становится клиентом OAuth 2.0. Это позволяет пересылать токен доступа (после того, как он был обменен на Код авторизации) для служб нижестоящих служб, если вы вызываете эти службы через OAuth2RestTemplate.
  • @EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties имеет только одно свойство String loginPath, которое по умолчанию /login. Это перехватит запросы браузера на /login на OAuth2ClientAuthenticationProcessingFilter и перенаправит пользователя на сервер авторизации.

Должен ли я использовать @EnableOAuth2Sso?

Это зависит:

  • Если вы хотите, чтобы ваш шлюз API был клиентом OAuth 2.0, который взаимодействует с браузером с помощью потока авторизации кода или потока полномочий учетных записей ресурсов ресурса, тогда ответ да, вы, вероятно, должны. Я сказал, вероятно, потому что я не уверен, что @EnableOAuth2Sso очень хорошо поддерживает поток учетных записей паролей ресурсов. Во всяком случае, я предлагаю вам перейти с помощью кода авторизации, если у вас нет (как и на самом деле!) Веских причин не делать этого. BTW, при использовании потока кода авторизации вы можете пометить ваши нисходящие микросервисы как @EnableResourceServer. Тогда API-шлюз будет OAuth 2.0 Client, а ваши микросервисы будут серверами ресурсов OAuth 2.0, которые мне кажутся логичными.
  • Если вам не требуется взаимодействие с браузером (например, Client Credentials Flow), или у вас есть SPA, который использует Implicit Flow, тогда вы должны использовать @EnableResourceServer, что означает что он будет принимать запросы только с действительным токеном доступа.