Oauth2 Spring Boot

Introduction

In any conventional client-server authentication model, the client authenticates with the server using the resource owner's credentials to access the restricted resource from the server.

To provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. In a simple language, share credentials, usernames, and passwords (Gmail, Facebook, etc.) with a third-party application so that they can get access to resources. Would you do that?

This has several problems and limitations.

• To continue with the access to the third-party application, the resource owner's credentials will be stored with the third-party application for future use.
• No control is in place with the resource owner on the duration of access and what subset of resources should be accessed. All resources become open to access with the third-party application.
• Compromise of any third-party application results in compromise of the resource owner credentials.
• Resource owner can not revoke access of individual third-party. Revoking access for one will revoke access for all authorized third parties.

OAuth addresses all the above issues by separating a resource owner from the client and having a separate authorization layer. As per OAuth standards, access to protected resources should use a secure token with specific scope and lifetime. That way resource owner does not need to share its credential with the third-party apps.

Don't worry for now if some of the above terms are unclear. We will get there in a bit.

OAuth Roles

Let's define a simple requirement and then understand how it correlates with the OAuth role.

Use case - You are building a photo printing service that should connect to logged-in user’s Google photos, download them and print them.

OAuth defines majorly four roles.

Resource Owner

The resource owner is the user who owns protected resources on any resource server. E.g., If you own certain files on Google Drive, you are the resource owner for those protected files. If you have an account on Twitter, Facebook, or Gmail, you are the resource owner for the data that belongs to that account.

OAuth2 Protected Resources (Not a role)

An artifact resource owner owns and protects.

Client

Piece of software that wants to access the protected resource on behalf of the resource owner.

The OAuth2 Resource Server

A resource server is a party that hosts the protected resource for a resource owner. Any protected resources on a resource server are accessible only to the resource owner once authenticated or to any client application to which the resource owner has granted access by getting an access token issued through the authorization server.

OAuth2 Authorization Server (AS)

A server that authenticates the Resource Owner and issues access tokens after getting proper authorization. Sometimes, the resource server and authorization server can be the same.

The table below represents the fitment of the OAuth roles for our use case.

How does OAuth Works?

Now that you have a decent idea of the OAuth 2.0 protocol and why it's important. OAuth is a complex protocol with different components talking to each other to perform its function. But the two most important steps are

1. Issuing a token and

2. Using a token

The token is the authority given to the client to access a protected resource on behalf of the resource owner.

An OAuth transaction consists of the following sequence:

1. The resource owner asks the client if they would like the client to act on their behalf. (For example, load my photos from Google Photos so that I can print them)
2. The client request authorization from the resource owner at the authorization server.
3. The resource owner grants authorization to the client.
4. The client receives a token from the authorization server.
5. The client uses the token to access the protected resources.

OAuth 2.0 Tokens

OAuth 2.0 provides two types of tokens when the grant is given to the client.

Access Token

Access tokens are granted by auth server with limited life. Auth server attaches expiry with the access token, after which it becomes invalid.

Refresh Token

A refresh token is similar in concept to that access token issued to the client. The difference is that this token is not for access to resources. Instead, the client uses a refresh token to request a new access token without involving the resource owner.

OAuth with Spring Boot

These days it's common for websites to allow you to do a social login on the home page.

For example, Scaler provides different social logins on Facebook, Linkedin, Github, and Google. That way, Scaler becomes an OAuth client, the User logging in is the resource owner, and the resource server and authorization server are with the individual social providers.

We will build a mini version of social login using spring boot with only one provider Github.

Let's code it!

1. Add starter-oauth2-client dependency in pom.xml

2. Configure our application to use GitHub as the authentication provider. To achieve this, do the following:
   • Add a New GitHub app - To use GitHub’s OAuth 2.0 authentication system for login, you must first Add a new GitHub app. 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.
   Once the above step is completed, you should get the client id and secret. Please make a note of it and keep it safe somewhere.

3. Configure application properties or YAML

4. Run the application Run the application using the runnable class and invoke the endpoint http://localhost:8080 from the browser. As soon as you do that, you will be redirected to the github for authorization.

What happens behind the scene? As soon as URL http://localhost:8080 gets invoked, you get redirected to github which redirects the request to the authorization server.

After successful authorization, the application's home page should be loaded.