What Is OAuth 2.0? A Deep Dive into the Authorization Protocol

Not long ago, I tried to implement Google OAuth login in one of my own web projects.
Although I haven’t fully succeeded yet, the process pushed me to deeply understand the architecture and purpose of OAuth 2.0.

Instead of randomly tweaking settings, I decided to learn how it all works under the hood.
This post summarizes what I’ve learned — both for myself and for others beginning their OAuth journey.

So What Exactly Is OAuth 2.0?

OAuth 2.0 is an authorization protocol that allows a third-party application to access specific resources on behalf of a user, without needing the user’s password.

The core idea:

• The user owns the data
• An application wants limited access
• The user grants permission without revealing credentials
• The application uses a token to act within those limits

When you see buttons like “Log in with Google” or “Connect with GitHub,” it’s OAuth 2.0 working behind the scenes.

Key Components of OAuth 2.0

Component	Role
Resource Owner	The user — owns the data
Client	The application requesting access
Authorization Server	Handles permissions (e.g., Google)
Resource Server	Holds the data (e.g., Google Drive APIs)

The Authorization Code Flow (for Web Apps)

This is the most common OAuth flow:

1. The app redirects the user to the authorization server (e.g., Google)
2. The user reviews and grants permission (e.g., “Allow access to email”)
3. The server returns an authorization code
4. The app exchanges the code for an access token
5. With the token, the app accesses APIs (like /userinfo)

At no point is the user’s password shared with the app.

Types of Tokens

Token Type	Description
Access Token	Used to access protected APIs (short-lived)
Refresh Token	Used to get new access tokens when the current one expires
ID Token	(with OpenID Connect) Used to identify the user (JWT format)

What Does OAuth 2.0 Secure?

• The app never sees the user’s password
• Permissions are scoped and limited
• Tokens are temporary and revocable
• The user stays in control of what’s shared

Where Is It Used?

• Login with Google, Facebook, GitHub, etc.
• Applications connecting to APIs (e.g., Google Calendar)
• Mobile apps accessing data securely
• Single Sign-On (SSO) systems in enterprises

What I Learned During My Implementation

As mentioned earlier, I tried integrating Google OAuth login into my own site.
I haven’t gotten it fully working yet — but I now understand the issues likely involve:

• Misconfigured callback URLs
• Incorrect or missing scopes
• Improper redirect or token handling

Through this experience, I realized:
It’s not enough to copy code — you need to understand what’s happening behind it.
Now, even if I haven’t solved it yet, I know what I’m looking at — and I’m way more confident going forward.

Common Use Cases for OAuth

• Allowing third-party services to act on a user’s behalf
• Mobile apps securely retrieving user data
• Slack bots, GitHub integrations, Google Drive sync
• SSO implementations across services

More on Tokens

• Access tokens are often valid for around 1 hour
• Refresh tokens can last days, weeks, or longer depending on settings
• ID tokens (when OpenID Connect is used) identify the user and are JWTs

What Are Scopes?

Scopes define what data the app can access:

scope=email profile calendar.readonly

In this case, the user is asked:

“This app wants to view your email, profile, and calendar (read-only). Allow access?”

Threats & Protections

Threat	Description	Mitigation
Token Theft	If stolen, a token can grant access	Use HTTPS, short lifetimes, PKCE
CSRF	Unauthorized app tricks user into granting access	Use state parameter
Token Replay	Old token reused maliciously	Use single-use codes, rotate refresh tokens

OAuth vs. OpenID Connect

Feature	OAuth 2.0	OpenID Connect
Purpose	Authorization	Authentication
Token	Access Token	ID Token (JWT)
Usage	API access	Logging in, identity sharing

OAuth 2.0 is more than a login tool — it’s a modern protocol designed for secure, delegated access without compromising user credentials.

“Access without password sharing” is the future of digital trust.

Even though I haven’t finished implementing it yet, the knowledge I gained while trying has changed how I approach identity and security.