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.
- 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".
- This is all about permissions and roles you are granted.
- The authorization will never expose your identity or your credentials.
- Simply this is all about who you are.
- If you are authenticated to a system, it means the system knows who you are.
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
- 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.
Basically, OAuth2.0 describes four roles. Let's compare these roles with our example
This is actually you, it means the owner of the protected resource.
This is the application that requests to access the protected resource.
Here it is soundcloud.com
This is the server that hosts protected resources.
Here it is google.com
This server issues access tokens
It can be Google or separate authorization servers Google uses.
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.
- This is suitable for pure single-page applications that don't have a backend.
- This is browser-based
- 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 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.
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.