What is 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 a protocol means?
- The protocol is just nothing but the official rules and regulations.
- It’s just a set of rules, just explain “how to do it” or “how to implement it”.
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, 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 on Soundcloud. Once you click on login, you will be able to see a window like the one 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 by 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)
- Device code
- Refresh
Mostly we are using Authorization code flow and implicit flow. Authorization code flow is more secure than others because it uses both channels.
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 do you want access of a user
- response_type
- state — A random string generated by your application
Step 02 — The 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 — The 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 the 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 — The 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 — The 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 the 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.