Most of the tutorials I've read so far uses @EnableOAuth2Sso
instead of @EnableResourceServer
on the API gateway. What are the differences? What the OAuth2Sso
does in contrast?
Details: I'm implementing a security/infra architecture for spring-based microservices and single page apps. For some time, while we didn't have security requirements, the SPAs talked directly to open microservices, on different hosts (CORS party).
Now I'm adding a layer of security and the gateway pattern using spring-oauth
and spring-zuul
. So I have a service (uaa-service) with @EnableAuthorizationServer
and a gateway with @EnableZuulProxy
& @EnableResourceServer
. I only need the password grant type, so each SPA has it's own login form and authenticates with uaa-service token endpoint, trough the gateway, and then proceeds to use that token for further requests.
Is there anything wrong with this approach? Should I be using @EnableOAuth2Sso
?
These annotations mark your services with different OAuth 2.0 roles.
@EnableResourceServer annotation means that your service (in terms of OAuth 2.0 - Resource Server) expects an access token in order to process the request. Access token should be obtained from Authorization Server by OAuth 2.0 Client before calling the Resource Server.
@EnableOAuth2Sso: marks your service as an OAuth 2.0 Client. This means that it will be responsible for redirecting Resource Owner (end user) to the Authorization Server where the user has to enter their credentials. After it's done the user is redirected back to the Client with Authorization Code (don't confuse with Access Code). Then the Client takes the Authorization Code and exchanges it for an Access Token by calling Authorization Server. Only after that, the Client can make a call to a Resource Server with Access Token.
Also, if you take a look into the source code of @EnableOAuth2Sso
annotation you will see two interesting things:
@EnableOAuth2Client
. This is where your service becomes OAuth 2.0 Client. It makes it possible to forward access token (after it has been exchanged for Authorization Code) to downstream services in case you are calling those services via OAuth2RestTemplate
.@EnableConfigurationProperties(OAuth2SsoProperties.class)
. OAuth2SsoProperties has only one property String loginPath
which is /login
by default. This will intercept browser requests to the /login
by OAuth2ClientAuthenticationProcessingFilter
and will redirect the user to the Authorization Server.Should I be using @EnableOAuth2Sso?
It depends:
@EnableOAuth2Sso
supports Resource Owner Password Credentials Flow very well. Anyway, I would suggest you moving with Authorization Code Flow unless you have really (like really!) good reasons not to do so. BTW, when using Authorization Code Flow you may want to mark your downstream microservices as @EnableResourceServer
. Then the API Gateway will be OAuth 2.0 Client, and your microservices will be OAuth 2.0 Resource Servers which seems logical to me.