Simple is not always better!
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- which we'll refer to as the resource server
authorization server- which handles the validation of credentials
This is a really straight-forward authorization flow.
- The user logs into a form in the
frontend-servicewith his username and password.
frontend-service, then forwards the user's information to the
authorization-serverto verify their validity.
- If the validation is successful, the
authorization-servergives back an
access_tokenwill 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 (
- 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.
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.
- 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
- Here he will use his credentials to login. If the credentials are correct, the
authorization-serversends a request to the
frontend-service( on a previously specified endpoint ) with an
authorization_code. Mind that this is not the
access_tokenrecognized by the
- In order to get the actual
frontend-serviceneeds to send back the received
authorization-server, along with the service's credentials. The
authorization-serveronly responds to known, authenticated services.
- If the
authorization_codeis correct and the
frontend-service, only now it returns the
- Finally, with this
frontend-servicecan access the
The advantages of this approach are:
- only one service knows the user's credentials
- the ping-pong with the
authentication_codekeeps us safe from attackers that could fake a redirect url to which the
access_token. By verifying the service's credentials we make sure that our application is the only one that receives to an
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.
frontend-serviceneeds a resource
- authenticate on the
authorization-serverusing the service's credentials
- receive an
- use the
access_tokento get the resource
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.
Stay tuned! 🚀