Getting Started with OAuth2

Table of contents

Reading Time: 4 minutes

Introduction

OAuth 2 is an authorization framework that enables applications like GitHub, Facebook, etc to obtain the limited access to user accounts on an HTTP service. OAuth 2 works by delegating user authentication to the service it hosts the user account and authorizing third-party applications to access that user account.

Principles of OAuth2.0

OAuth 2.0 is NOT an authentication protocol, it is an authorization protocol. It is designed as a means of providing access to a set of resources, for example, remote APIs, user data, etc.

OAuth 2.0 uses Access Tokens. An Access Token is a code that represents the authorization to access resources on behalf of the end-user. It does not declare a specific format for the Access Tokens. In OAuth 2.0, mostly the JSON Web Token i.e. JWT format is used. It allows token issuers to contain data in the token itself.

Maven Dependencies

In a Spring Boot project, we just need to add the starter spring-boot-starter-oauth2-client:

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

OAuth Terminologies

Resource Owner: The resource owner is the user who authorizes an application for accessing their account. The application’s access to the user’s account is restricted to the “scope” of the authorization granted for example read or write access.
Client: The client is the application that tries to access the user’s account. The client needs to get permission from the user before accessing the user account. For example, for accessing a particular resource, the client application can present the user with the login page to get an access token for it.
Authorization Server: It is the server that validates the user credentials and redirects the user back to the client with an authorization code. To exchange the code for an access token, the client communicates with the authorization server to confirm its identity.
Resource Server: It is a server for access-protected resources. It handles authenticated requests from an application that has an access token.
Scope: Scope specifies the level of access that the application is requesting from the client.
Consent: The consent screen tells your users what kind of data they’re asking to access and who is requesting access to their data.

Architecture

The user accesses resources using the client application like Google, Facebook, LinkedIn, etc.

After that, the client app will be provided with the client (id and password) during registering the redirect URI (Uniform Resource Identifier).

User logs using the authenticating application. On the authorization server, the client iD and client password are unique to the client application.

The authenticating server redirects the user to a redirect Uniform Resource Identifier (URI) using an authorization code.

Then user accesses the page at the redirect URI in the client application.

Next, the client appl will be provided with the client id, client password, and authentication code and sent to the authorization server.

Next, the authenticating application returns an access token to the client app.

Once the client application gets an access token, then the user starts accessing the resources of the resource owner using the client application.

Grant Types in OAuth 2

1. Authorization Code Grant

The Authorization server returns a single-use Authorization Code to the Client, which is then interchanged for an Access Token. This is the best option for traditional web apps where the interchange can securely happen on the server side. The Authorization Code flow might be used by mobile/native apps and Single Page Apps (SPA). However, here, the client secret cannot be stored securely, and so authentication, during the exchange, is limited to the use of the client id alone.

2. Proof Key for Code Exchange (PKCE)

It is a security-centric OAuth grant type. The main concept behind Proof Key for Code Exchange is proof of possession. So it basically means that before getting an access token from it, the client application needs to prove to the authorization server that the authorization code is authentic. The PKCE flow includes a code challenge and a code verifier, also a code challenge method.

3. Device Code Grant

The Device Code Grant type is used by input-constrained devices (like IoT) in the flow to interchange a previously obtained device code for an access token.

4. Client Credentials Grant

The Client Credentials Grant is used for non-interactive applications. For Example automated processes, microservices, etc.

5. Refresh Token Grant

As the name suggests, Refresh Token Grant are essentially user credentials that help to obtain Access Tokens. These tokens are given by the authorization server and are used to obtain new access tokens when the old one expires or turns invalid. Refresh Tokens can also be used to obtain supplementary access tokens with a more limited scope (e.g., where the security is crucial).

Security Configuration

we have to add the following credentials to the application.properties file of our application.

spring.security.oauth2.client.registration.github.client-id=<Client-Id>
spring.security.oauth2.client.registration.github.client-secret=<Client-Secret>

We have to add the following configuration to our application.

@Configuration
@EnableWebSecurity
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
       http
            .authorizeRequests()
            .antMatchers("/").permitAll()
            .anyRequest().authenticated()
            .and()
            .oauth2Login();
    }
}

Advantages of OAuth 2

This protocol relies on SSL (Secure Sockets Layer) to ensure data between the browsers and web server remain private.
SSL uses cryptography industry protocols to keep data safe.
It uses tokenization to give limited access to the user’s data. For example, instead of storing credit card information on Amazon’s website, the credit card number, security code, and consumer name are each given “token” IDs. The tokens are given to the merchant, not the actual data.
It is easy to implement and provides strong authentication. In addition to the two-factor authentication, tokens can be revoked if necessary (ie, suspicious activity).
Uses single sign-on.