Spring @EnableResourceServer vs @EnableOAuth2Sso

Question

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?

Answer 1

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:

• If you want your API gateway to be an OAuth 2.0 client which interacts with the browser using Authorization Code Flow or Resource Owner Password Credentials Flow, then the answer is yes, you probably should. I said probably as I am not sure if @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.
• If you do not need interaction with the browser (e.g. Client Credentials Flow) or you have SPA that makes use of Implicit Flow then you should use @EnableResourceServer, meaning that it will accept requests with valid Access Token only.