Understanding OAuth2: A Beginner-Friendly Guide

Introduction

I had heard about OAuth2 many times, but I never really understood what it was, since I had never worked on implementing authentication and authorization myself.
If you are in the same boat, this post is for you!

Before we jump into OAuth2, let’s review some basic terminology you should know:

Authentication

• is the step that you verify the identity of the user.
• verifying who you are

Authorization

• is the step that you verify the permission of the user.
• verifying what you’re allowed to do

What is OAuth2?

OAuth2 is a security standard that allows one application to access user data from another application on the user’s behalf without needing the user’s password.

For example, when you log into a website using your Google account, OAuth2 allows that website to access your data without seeing your password.

Many organizations provide authorization servers that follow the OAuth2 framework, such as Okta, Keycloak, Auth0, and AWS Cognito.

The main terminologies in OAuth2

1. Resource Owner is the end user who owns the data.
2. Client is the application that wants to access data.
3. Authorization Server is the server that knows about resource owners, handles the login process, and issues tokens.
4. Resource Server is the data provider that hosts the protected data.

Common Grant Types

Each grant type is for different use cases

1. Authorization Code

📌 Use case
When an end user is involved, and the client is a trusted backend server.

📌 How it works

• After the user authorizes, the client receives an authorization code from the authorization server.
• The client sends authorization code with the client secret for an access token.
• The authorization server issues the access token if valid.

📝 Note:

• The client in this diagram represents both the frontend and backend together. In practice, the frontend handles redirecting the user to the provider, while the backend exchanges the code for tokens.
• The client must be registered with the authorization server before it can request tokens and access protected resources.

2. PKCE

PKCE = Proof key for code exchange

📌 Highlight
very similar to the authorization code, but no client secret is involved

📌 Use case
When an end user is involved, but the client cannot safely store a client secret, such as a JavaScript application.

📌 How it works

• The client generates a code verifier and code challenge.
• The code challenge is sent in the initial authorization request.
• After the user authorizes, the client receives an authorization code.
• The client sends the authorization code along with the code verifier for an access token.
• The authorization server checks if the original code challenge matches the newly calculated one using the code verifier and issues the access token if valid.

3. Client Credentials

📌 Use case
When two backend applications communicate with each other, and an end user is not involved.

📌 How it works

• The client authenticates using client ID and client secret.
• The authorization server returns the access token directly.

4. Refresh Token

📌 Use case
When the access token expires, behind the scenes, the client application initiates this flow without involving the end user.

📌 How it works

• The client stores a refresh token after the initial login.
• When the access token expires, the client sends the refresh token to get a new one.

Bonus: How the Resource Server Validates Tokens

1. Validating remotely

• The token is in an opaque format (a random string with no readable info)
• The resource server will send the access token to the authorization server to validate by calling the introspection endpoint exposed by the authorization server.

2. Validating locally

• The token is JWT (JSON Web Token) format
• The resource server can verify the token itself.
• The secure approach is to use a JWKS (JSON Web Key Set).
  • The authorization server has a private key to issue the access token
  • The resource server uses a public key to validate it.

Conclusion

• OAuth2 is a security standard that helps with authorization between applications.
• It allows applications to access user data without needing the user’s password.
• It provides different grant types to support different use cases:
  • When an end user is involved → Authorization Code
  • When an end user is involved but the client can’t store a secret → PKCE
  • When no end user is involved (server-to-server) → Client Credentials
  • When the access token expires → Refresh Token

Reference

I learned a lot from this Udemy course: Spring Security Zero to Master on Spring Security, including OAuth2, which explained the grant types clearly.
Note: I’m not affiliated with this course — I just found it very helpful!