Designing an OAuth 2.0 Authorization Server from scratch

What is an Authorization Server?

Let’s say you are trying to log into some application such as LinkedIn, where you will be given an option to ‘Continue with Google’. Using this you will be entering your Google account credentials and you are signed in.

A generic overview of what actually happened 👇

Your Gmail credentials are already stored at Google therefore it will be acting as an authorization server which validates the details you supplied via the LinkedIn sign-in page and will let the app know that you are a verified user.

Architecture of OAuth 2.0

Suppose that a user wanted to analyze his most viewed YouTube videos and understand the nature of his audience. In order to do this, he wanted to use a third-party app.

The below diagram depicts the architecture of OAuth 2.0 for this particular scenario

Designing an Authorization Server

As shown in the above architecture diagram, the main aim of the authorization server is to validate the user details and generate the token.

That said, we have multiple approaches to how this validation and token generation is being done.

Some of them are outlined below:

1. Authorization Code Grant Type
2. Client Credentials Grant Type
3. Refresh token Grant Type
4. Password Grant Type
5. Resource Owner Grant Type
6. PKCE

As an example, we will be considering the Authorization Code Grant Type here.

Working of Authorization Code Grant Type

Functional Requirements

The User and Client would be our key persona while designing an authorization server.

The functional requirements for these are mentioned below.

1. User :

• Registering user details at the authorization server
• Fetch the user details

2. Client :

• Registering the client details at the authorization server
• Fetch the client’s details

Other requirements include :

• Generate the Authorization Code
• Generate the Access Token

Implementation Details

1. For each of the mentioned above requirements, we would be exposing an endpoint.
2. User Registration and Client Registration would be publicly accessible APIs.
3. Client Registration would also include a field called ‘scopes’ which can be used to control the level of access. In the above example, we just need the client to fetch the most viewed videos. The scope should be restricted to ‘read’ and prevent it from performing any additional actions.
4. All the user passwords, client secrets and authorization codes are stored in an encrypted format.

The GitHub link to the spring boot implementation is here