The story of OAuth 2.0



This is a brief introduction to OAuth 2.0. You may have already heard terms like authorization, authentication, OAuth, OAuth 2.0, OpenID, OpenID Connect, JWT, SSO...etc. It is just like a mess for beginners. When it comes to security the major points are Authentication and Authorization. Before we learn about these things, let's discuss some basics.


What is the protocol means?

  • The protocol is just nothing but the official rules and regulations.
  • It just a set of rules, just explain "how to do it" or "how to implement".

What is authorization?

  • This is all about permissions and roles you are granted.
  • The authorization will never expose your identity or your credentials.

What is authentication?

  • Simply this is all about who you are.
  • If you are authenticated to a system, it means the system knows who you are.

Login without registration

Can you manage hundreds of usernames and passwords? This is ridiculous. Instead of managing many usernames and passwords, now you can log in via an existing account. It can be Google, Facebook, or any other social media account or any private account.

For example, just think you are going to login to Soundcloud. Look at the following process. You can log in to Soundcloud via your Google account without creating separate accounts in Soundcloud. Once you click on login, you will be able to see a window like below.

If you click "Continue with Google". Then a separate window opens. You can see the URL, it is Google and asked you to enter your email and password. You are not passing your credentials to a third party.


Once you are identified from Google, you are successfully login to Soundcloud. This is very convenient, secure, and easy. Under the hood, it is the process of OAuth2.0

What is OAuth2.0?

  • OAuth2.0 is an authorization protocol. 
  • It explains how to delegate the authorization.
  • This works over HTTP
  • This can be used to authorize applications, servers, devices...etc
  • The token-based authentication depends on OAuth 2.0
  • OAuth2.0 will never share your identity or credentials.
  • Mainly this is used external applications to access any secure content.

Roles of OAuth2.0

Basically, OAuth2.0 describes four roles. Let's compare these roles with our example
  • Resource owner
    • This is actually you, it means the owner of the protected resource.
  • Client
    • This is the application that requests to access the protected resource.
    • Here it is soundcloud.com
  • Resource server
    • This is the server that hosts protected resources.
    • Here it is google.com
  • Authorization server
    • This server issues access tokens
    • It can be Google or separate authorization servers Google uses.

OAuth2.0 authorization channels

OAuth2.0 uses a two-way channel process to make sure of a very secure authorization process. According to the situation, we can use the front channel, back channel, or both channels.
  • Front channel
    • This is suitable for pure single-page applications that don't have a backend.
    • This is browser-based
  • Back channel
    • This is server-based
    • Back channel is not visible to front-end
You will be able to understand these channels later on in this post. Keep reading. 

Authorization flows of OAuth2.0

  • Authorization code flow (front channel + back channel)
  • Implicit flow (front channel only)
  • Resource owner password credentials flow (back channel only)
  • Client credentials flow (back channel)
Mostly we are using Authorization code flow and implicit flow.

OAuth2.0 authorization code flow



  • In the above diagram, front channel flows are directed in green arrows and back channel flows are directed in dashed green arrows.
  • The back channel process is not visible to the user.

Steps in the authorization flow

Step 01 - Client app requests from the Authorization server

Client application -> Authorization server
  • client_id (Not the client_secret)
  • redirect_uri - Indicates the return URI
  • scope - Which parts you want access of a user
  • response_type
  • state - A random string generated by your application


Step 02 - Authorization server sends the authorization code to the client application

Authorization server -> Client application
  • code - authorization code
  • state - return the same state value generated


Step 03 - Client app exchanges the authorization code with the Authorization server

Client application -> Authorization server
  • grant_type - authorization_code,client credentials, refresh token
  • code - received code in first steps
  • redirect_url - Indicates the return URI
  • client_id - client id of the client application when registering with the auth server
  • client_secret - provided client secret


Step 04 - Authorization server sends the access token to a client application using the back channel

Authorization server -> Client application
  • access_token - the token that can be used to access the resource server
  • expire_in - expiration time


Step 05 - Client application calls the resource server with the received access token

Client application -> Resource server

Now client application can use the access token to access the resource server

Authentication with OAuth2.0

  • Authentication is not possible with OAuth2.0 specification
  • Because it doesn't mention any standard way to retrieve user details.
  • OAuth 2.0 is all about authorization, not authentication.
  • If you want authentication, you can go with OpenID Connect which provides an additional id token that contains user information.

More about OAuth2.0

  • Token-based security depends on the OAuth2.0
  • Nowadays JWT is the most popular token format in the industry.
  • You can use Spring Security to implement token-based authorization and authentication in your Spring applications.
  • Spring Security provides many standard features.





The story of OAuth 2.0 The story of OAuth 2.0 Reviewed by Ravi Yasas on 11:35 AM Rating: 5

No comments:

Powered by Blogger.