OAuth2.0 Tutorial - PART - 6

 

OAuth Tokens

Tokens basically are random strings generated by the authorisation server and are issued when the client requests them.

There are 2 types of token being used in OAuth 2.

Access Token: This is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorisation server.

Refresh Token: This token is issued with the access token but it is not sent in each request from the client to the resource server. When access token validity is finished or access token is expired then It could be sent to the authorisation server for renewing the access.

Authentication V/S Authorization

Authentication means verifying that someone is indeed who they claim to be. Authorisation means deciding which resources a certain user should be able to access, and what they should be allowed to do with those resources. Oftentimes, as in our case, an application will require a little bit of both.

Or,

Authentication refers to verifying your identity to an application that you are trying to access. Any application(eg. gmail) recognises who you are based on your username and password. Authorisation refers to what you can access based on your identity.

A Sample example to show implementation of OAuth 2

A Spring Boot Application with OAuth 2 Implementation Link :

http://javatipsbygaurav.blogspot.com/2018/07/spring-boot-security-using-oauth2-with.html

Basically, while implementation of OAuth2, We need to focus on main 4 classes:-

Resource Server  - API

Authorization Server  - API

Resource Owner   - Employee ( As per the given example)

Client  - Application

Authorization Server : This class extends AuthorizationServerConfigurerAdapter and is responsible for generating tokens specific to a client. Suppose, if a user wants to login to deque.com via LinkedIn then LinkedIn auth server will be generating tokens for Deque. In this case, Deque becomes the client which will be requesting for authorisation code on behalf of user from LinkedIn - the authorisation server.

Resource Server : Resource in this context is the REST API which we have exposed for the some operations. To access these resources, client must be authenticated. In real-time scenarios, whenever an user tries to access these resources, the user will be asked to provide his authenticity and once the user is authorized then he will be allowed to access these protected resources.