OAuth-The Concept : Getting Started!

What is it really ?

• Open Authorization (not Authentication)
• Meant for one service to authorize resources of another service and not to authorize a person.
• Authorization without having to give credentials

OAuth, in general, is an authorization mechanism where services can authorize against each other on one’s behalf once permission is granted by the user.

Currently, the widely used version is Oauth2 (as in 2.0).

A Simple Analogy

Suppose you are going to attend a party of a colleague in a grand hotel where you arrive in your expensive car. Before you enter the party, your car needs to be parked. For these particular reasons, these hotels have people who assist you in parking your vehicles. These people are known as valets.

But these valets are not provided with the original key of the vehicle. Instead they are given a valet key. It is only authorized to start and stop the car. Meaning, it cannot open the fuel tanks, trunks or any other personal compartments. Basically, it has reduced access.

Similar is the concept of oauth. The level of access to the resource for some other service is completely decided by the resource owner.

Workflow along with an example

We have four major components acting within the workflow:

1. The Client App that wants to access the protected resource from the resource server.
2. Authorization Server which is responsible for the authorization of the user and generation of access token.
3. The Resource Server that holds the protected resource.
4. Resource Owner who is capable of granting access to a protected resource.

Authorization Flow Diagram

Let’s assume we built and deployed an application, PhotoCart. This application wants to access some protected resource and display it onto its own dashboard. Let’s say the protected resource is google photos and the application wants to retrieve some photos and display it.

So how is authorization granted to the application? The following steps will explain the process:

1. Initially when a user asks to connect to the resource, the PhotoCart application will make a request to the authorization server.
2. An authorization screen is displayed to the user asking to authorize PhotoCart to access the user’s account.
3. After the user grants the permission, the auth server sends the authorization along with an authorization code. This code will be used to request for an access token later by PhotoCart app.
4. The PhotoCart app then requests for an access token by sending the authorization code to the auth server.
5. The auth server verifies the code, generates an access token and sends it to the requesting application. This token contains only those permissions granted by the user.
6. Subsequently, the application requests for the resources from the resource server by adding this token in the request.
7. The resource server validates the token and finally returns the protected resources.

Note that throughout this workflow oauth serves as authorization framework. The authentication of the user occurs with the use of openID connect through the use of an id token passed along the access token.

However, for all of this process to work, the PhotoCart application needs to be registered to the resource server. The API containing name, website and callback URL(to which the authorization screen will redirect after successful authorization) must be provided. After these information are provided, the auth service API will return back a set of credentials which contains Client Id and a Secret.

Client Id is a public and unique identifier that will be used to identify the PhotoCart application. Client secret is a private identifier kept secret between the app and the API used to authenticate the PhotoCart application when it makes a request for the access token.

As we can see in the image above, the first few steps are essentially getting the user’s permission to access the protected resource in the user’s account. In OAuth2, there are basically four different grant types for different use cases:

1. Authorization Code Grant (The one used in the example)
2. Implicit Grant
3. Password Grant
4. Client Credentials Grant

Basically, there are two ways in which we can implement OAuth2. We can either use an already built authorization server (third-party like github,google) or build our own Authorization server.

Spring Boot with OAuth2: (External OAuth2 provider)

One way of implementing oauth into our spring boot app is by using any login provider (like github, facebook, linkedIn, google) single-sign on option.

Create a new Spring boot application by going to https://start.spring.io. To simply demonstrate oauth2 features, we will require the oauth 2.0 client starter dependency.

<dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>

By adding that, it will secure our app with OAuth 2.0 by default. Say, we want to use Github as the authentication provider for our app. For that, we need to configure our app to use github. To achieve this, we do the following:

1. Add a new github app: Registering a new oauth application at https://github.com/settings/developers.

Select “New OAuth App” and then the “Register a new OAuth application” page is presented. Enter an app name and description. Then, enter your app’s home page, which should be http://localhost:8080, in this case. Finally, indicate the Authorization callback URL as http://localhost:8080/login/oauth2/code/github and click Register Application.

The OAuth redirect URI is the path in the application that the end-user’s user-agent is redirected back to after they have authenticated with GitHub and have granted access to the application on the Authorize application page.

2. Configure the application.yml file

3. Run the application: With that change, you can run your app again and visit the home page at http://localhost:8080. Now, instead of the home page, you should be redirected to login with GitHub. If you do that, and accept any authorizations you are asked to make, you will be redirected back to the local app, and the home page will be visible.

To Summarize the process:

The app we just wrote, in OAuth 2.0 terms, is a Client Application, and it uses the authorization code grant to obtain an access token from GitHub (the Authorization Server).

It then uses the access token to ask GitHub for some personal details (only what you permitted it to do), including our login ID and name. In this phase, GitHub is acting as a Resource Server, decoding the token that we sent and checking if it gives the app permission to access the user’s details. If that process is successful, the app inserts the user details into the Spring Security context so that we are authenticated.