Understanding OAuth 2.0: Why Every Developer Should Know This Protocol
Table of Contents
- Introduction
- What You Will Learn
- Tech Stack
- Prerequisites
- What Is OAuth 2.0?
- The Four Core Roles in OAuth 2.0
- A Real-World Example: Logging Into Spotify with Google
- Why Use OAuth 2.0?
- Conclusion
Introduction
Authentication is one of those topics developers encounter early and often, yet rarely stop to understand deeply. In this article, I want to walk you through OAuth 2.0, what it is, how it works under the hood, and why understanding it will make you a better developer regardless of which stack you build on.
OAuth 2.0 is so deeply embedded in the modern web that Google’s OAuth appears on nearly 4% of all analyzed websites and underpins billions of sign-ins each year, yet many developers still treat it as a black box.
Sources:
- https://www.arcade.dev/blog/oauth-authentication-statistics/
- https://blog.arcade.dev/oauth-authentication-statistics
- https://www.authgear.com/post/what-is-oauth-2-0-and-how-it-works
What you will learn
By the end of this article, you will understand the core concepts behind OAuth 2.0, be able to identify the four key roles involved in any OAuth flow, follow a real-world authorization scenario from start to finish, and understand why delegated access is both a security and user experience improvement over traditional credential sharing.
What is OAuth 2.0 ?
At its core, OAuth 2.0 is an open standard protocol that allows users to share private resources stored on one platform with another platform, without ever exposing their credentials to the requesting application.
Put simply:
OAuth 2.0 is a way to let your app access someone's account without ever knowing their password.
That single idea has enormous implications for both security and user experience, and it is what made OAuth 2.0 the dominant authorization framework on the web today.
source: https://frontegg.com/blog/oauth-2
The Four Core Roles in OAuth 2.0
The following diagram shows the roles of the API Gateway as an OAuth 2.0 Resource Server and Authorization Server:
To understand any OAuth flow, you need to know the four roles the protocol defines. Every OAuth interaction, no matter how simple or complex, involves these same four players.
The Resource Owner is the person who owns the data being accessed. When a human is involved, this is simply the end user sitting at their laptop, deciding whether to grant an application access to their account.
The Client Application is the app requesting access to the resource owner's data. It acts on behalf of the user and must be granted authorization before it can access anything. Crucially, it never sees the user's actual credentials.
The Authorization Server is the server responsible for authenticating the resource owner and issuing access tokens once authorization is granted. It is the gatekeeper of the entire flow.
The Resource Server is the server that actually hosts the protected data. It accepts requests that carry valid access tokens and responds accordingly. In many modern implementations, the Authorization Server and Resource Server are operated by the same provider.
source: https://docs.oracle.com/cd/E50612_01/doc.11122/oauth_guide/content/oauth_intro.html
A Real-World Example: Logging Into Spotify with Google
Abstract definitions only go so far. The best way to understand OAuth 2.0 is to trace through a concrete scenario. Imagine you open Spotify and click "Continue with Google.”
You, the Resource Owner, want to access Spotify's features, but Spotify does not know who you are yet. Rather than ask you to create yet another username and password, Spotify, acting as the Client Application, redirects you to Google's login page. You enter your Google credentials there, and Google, acting as the Authorization Server, verifies your identity. Once verified, Google issues an Access Token and sends it back to Spotify.
Spotify now holds that token. It uses it to call Google's API and retrieve only the information it was authorized to access, typically your name and email address, to create your account. At no point does Spotify ever see or store your Google password.
On Google's side, the Resource Server is what actually responds to Spotify's token-bearing requests and returns your profile data. Meanwhile,
Google's internal monitoring layer continuously watches for suspicious behavior. If Spotify were to suddenly make thousands of API calls per second, Google's systems can rate-limit or revoke the token entirely. This monitoring component is what keeps the whole ecosystem trustworthy at scale.
Why Use OAuth 2.0?
Beyond the conceptual elegance, there are three practical reasons to build with OAuth 2.0.
The first is better security. Applications never see or store your real credentials. They only receive tokens that are limited in scope, meaning they can only access what you explicitly authorized, and limited in lifetime, so even if a token is leaked, the damage is contained.
The second is delegated access. A user can grant an application access to a specific slice of their data for a specific period of time, without handing over full control of their account. This granularity is a major improvement over older approaches.
The third is fewer passwords for users. People can log in or grant access using an account they already trust, such as Google, Microsoft, or GitHub, rather than creating yet another set of credentials. This reduces friction and improves conversion, which is why we chose to implement OAuth in our own project. We wanted users to register and access the dashboard as seamlessly as possible.
Conclusion
OAuth 2.0 is one of those foundational protocols that rewards the time you invest in understanding it. Once you can trace through the four roles, Resource Owner, Client Application, Authorization Server, and Resource Server, in any login flow you encounter, the internet starts to look a little less like magic and a little more like well-designed engineering.
Thanks for reading.
Here is an article where I explain exactly on I implemented OAuth protocol in my project : https://www.alainngongang.dev/posts/real-life-use-case-codex-website-authentification-using-oauth-2-0
Alain Ngongang