OAuth2 with Spring — Part-1: Knowing the basic concepts

In this series of OAuth2 with Spring I will try to cover and explain each and every concerns related to OAuth2 and how to implement those in Spring framework. Please try to keep in mind that OAuth2 is completely a conceptual thing and in different framework, it has their own implementation. Also, many application developers develop their own OAuth2 implementation without using the OAuth2 framework support provided by Spring framework. Therefore, I will write a series of posts on this topic.

What is OAuth2 and Why?

According to Octa, OAuth2 is an open standard for authentication and authorization. It is not actually a service, but it works to secure a service by providing token based security over TLS. It authorizes devices, servers, APIs and applications with tokens instead of credentials.

The main focus behind OAuth2 was to let users access to several applications that can use the same authentication and authorization information from a single point or provider. It means, login with user ID and password is not always required. Instead of that user will be redirected to the authorization server, who has user’s identity and user will allow other applications to use his authentication information just by a click. Once that is authorized, user can use that with the same ID from authorization server.

OAuth2 Actors and Grant Types

a) Actors

For the OAuth2 architecture, there are 4 actors —

• Resource Owner — the user who has his own authorization information (usually username, password, role etc) in Authorization Server
• Client — Client can be considered as the app by which Resource Owner will be able to request for the secured resource in Resource Server
• Authorization Server — The server that will reside in the middle of Client and Resource Owner and check for authentication and authorization
• Resource Server — Contains the resource that the Resource Owner wants to access.

b) Grant Types

OAuth2 has several grant types to request for an access token. The sole purpose of grant types are to generate access token. The grant types are -

• Authorization code grant — To receive an access token, authorization client sends a request to the authorization server along with the authorization code, which was previously received from the authorization server. Part — 3 of this series is dedicated for this Authorization code grant.
• PKCE — Proof Key for Code Exchange (PKCE) is an extended version of Authorization code grant, introduced to support Single Page applications or mobile applications to prevent CSRF or Authorization Code injection attacks.
  PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication. Part — 5 of this series describes the code example for this flow.
• Client Credential — In this flow, a client application requests with a client_id and client_secret and the grant type is client_credential. It happens usually for 3rd party applications using a service. Part — 2 of this series is dedicated for this Client Credentials.
• Refresh Token Grant — This grant type is used by clients. When the access token becomes expired, the refresh token stored in the client memory is sent to the authorization server with grant type refresh_token. The server responds a new access_token in return. We will not have any dedicated article, since it is mostly handled internally by the applications.

Understanding the workflow for receiving an access token

OAuth workflow

• To request for some resource in resource server, resource owner requires an access token
• The resource owner opens an application (which is potentially a client of authorization server, in above diagram, BusinessClient) to request for some secured resource in resource server.
• When resource owner requests for a resource without any token, he/she is given option to choose the authorization server.
• Upon selection, the client is redirected to authorization server (OAuthSercer). Authorization server asks for the username and password (also the grant_type).
• Resource owner provides the required information and submits. If the information are authentic, authorization server sends the access token (and also other information, optional) to the client.
• Client saves the token and creates the request internally for the resource, which resource owner made when he had no token.
• Upon receiving the token, resource server sends it to authorization server for validating the token.
• If authorization server provides a positive response to the resource server, resource server responses with information resource owner requested for.

This is how the whole process works. In my next post, I will jump into code and demonstrate OAuth2 implementation with in-memory client.

References:

1. OAuth2 Grant Types — https://oauth.net/2/grant-types/
2. OAuth2 Roles — http://websystique.com/spring-security/secure-spring-rest-api-using-oauth2/