Spring Security (series) - OAuth Grant Types #4

Simple is not always better!

Brief

Let's start with understanding what a Grant Type actually means.  

The OAuth grant type defines the flow of the whole OAuth process. It also affects how the client application communicates with the authorization server at each step, including how the access token itself is retrieved.

We'll demonstrate the most common OAuth grant types having as an example a web application made of:

• frontend service - which the users access to interact with resources. It communicates with the backend service
• backend service -  which we'll refer to as the resource server
• authorization server - which handles the validation of credentials

Implementation

Password (deprecated)

This is a really straight-forward authorization flow.

1. The user logs into a form in the frontend-service with his username and password.
2. The frontend-service, then forwards the user's information to the authorization-server to verify their validity.
3. If the validation is successful, the authorization-server gives back an access_token
4. The access_token will then be added on the request to the resource server.

This one became deprecated since we have a lot of points where vulnerabilities can occur.

• multiple components have access to user's credentials ( frontend-service and authorization-server )
• encourages phishing attacks
• doesn't support Multi Factor Authentication (MFA) or Single Sign On (SSO)

We can use this grant type for demo purposes since it's really direct, but in a live application it's highly discouraged.

Authorization code

This is the one usually used in production services. It's a bit more complex, but the upside is that it's less vulnerable to malicious attacks.

1. The user asks for a resource and is requested to login. Now, the login will not be handled anymore by the frontend-service, instead, the user will be redirected to the authorization-server.
2. Here he will use his credentials to login. If the credentials are correct, the authorization-server sends a request to the frontend-service ( on a previously specified endpoint ) with an authorization_code. Mind that this is not the access_token recognized by the resource-server.
3. In order to get the actual access_token, the frontend-service needs to send back the received authorization_code to the authorization-server, along with the service's credentials. The authorization-server only responds to known, authenticated services.
4. If the authorization_code is correct and the authorization-server recognize the frontend-service, only now it returns the access_token.
5. Finally, with this access_token, the frontend-service can access the resource-server.

The advantages of this approach are:

• only one service knows the user's credentials
• the ping-pong with the authentication_code keeps us safe from attackers that could fake a redirect url to which the authorization-server sends the access_token. By verifying the service's credentials we make sure that our application is the only one that receives to an access_token.

Client credentials

This grant type is used when services in our ecosystem are doing actions without the need for a user intervention. They only rely on service credentials which are internally managed and thus, harder to be accessed by bad intended users.

1. frontend-service needs a resource
2. authenticate on the authorization-server using the service's credentials
3. receive an access_token from the authorization-server
4. use the access_token to get the resource

Authorization server

In terms of the authorization-server component, there are MANY out of the box providers that you can choose from like Okta or Keycloak. You can also implement your own using Spring's Authorization Server implementation and customizing it, the way you want.