A Brief History of OAuth

Understanding what is OAuth requires knowing why it was created.

Before OAuth, if you wanted to give an app access to your Gmail contacts, the only option was to give that app your Gmail username and password directly. The app would log in as you and grab what it needed. The problems were obvious:

• The app could access everything — not just contacts
• You could not revoke access without changing your password
• If the app was compromised, your password was too

In 2006, Twitter engineers and Google’s OpenID team recognized this problem and began working on a solution. OAuth 1.0 was published in 2010. OAuth 2.0 followed in 2012 with simpler flows and better support for mobile apps.

Today, OAuth 2.0 powers billions of authorization events daily. It is the backbone of the modern “sign in with” ecosystem.

8 Powerful Concepts of OAuth

Concept 1: The Problem OAuth Solves 🔐

Before diving into how OAuth works, it helps to understand what is OAuth specifically solving.

Imagine you want to use a third-party app called “PrintMyPhotos” that prints your Google Photos. Without OAuth, the flow would be dangerous:

Old Way (Dangerous):
PrintMyPhotos: "Give us your Google email and password"
You: [Gives password]
PrintMyPhotos: Logs into Google as you
                → Can read your emails
                → Can delete your photos
                → Can access your Drive
                → Can access everything

This is called the password anti-pattern — and it is terrible for security. The third-party app gets way more access than it needs, and you have no way to revoke it except changing your password.

What is OAuth’s solution?

OAuth Way (Safe):
PrintMyPhotos: "Click here to authorize with Google"
Google: "PrintMyPhotos wants to access your Photos. Allow?"
You: "Yes, allow"
Google: Gives PrintMyPhotos a limited access token
PrintMyPhotos: Uses token to access Photos ONLY
               → Cannot read your emails
               → Cannot access your Drive
               → Token expires automatically
               → You can revoke it any time

That is the core value of what is OAuth — delegated, limited, revocable access.

Concept 2: The Four OAuth Roles 👥

What is OAuth’s structure built around? Four distinct roles that every OAuth flow involves.

1. Resource Owner The user — the person who owns the data and can grant access to it. When you click “Login with Google,” you are the resource owner.

2. Client The application requesting access to the user’s data. In the PrintMyPhotos example, PrintMyPhotos is the client. It wants permission to access your Google Photos.

3. Authorization Server The server that handles the login and permission process. It verifies the resource owner’s identity and issues access tokens. Google’s authorization server is accounts.google.com.

4. Resource Server The server that hosts the protected resources — the actual data. Google Photos API is the resource server. It accepts tokens and returns the data.

Resource Owner (You)
        ↕
Client App (PrintMyPhotos)
        ↕
Authorization Server (Google Login)
        ↕
Resource Server (Google Photos API)

In many systems, the Authorization Server and Resource Server are the same service — but conceptually they serve different functions.

Concept 3: How OAuth 2.0 Works — Step by Step ⚙️

This is the heart of understanding what is OAuth. Let us walk through the most common OAuth flow — the Authorization Code Flow — step by step.

Scenario: You want to use PrintMyPhotos and it asks you to sign in with Google.

Step 1 — Client redirects user to Authorization Server

PrintMyPhotos sends you to Google’s login page with a special URL:

https://accounts.google.com/o/oauth2/auth?
  client_id=printmyphotos-123
  &redirect_uri=https://printmyphotos.com/callback
  &response_type=code
  &scope=photos.readonly
  &state=random-secure-string

Key parameters:

• client_id — Identifies PrintMyPhotos to Google
• redirect_uri — Where Google sends you back after login
• scope — What access is being requested (photos only, read-only)
• state — A random string to prevent CSRF attacks

Step 2 — User authenticates and grants permission

You see Google’s login page. You log in (if not already) and see: “PrintMyPhotos wants to access your Google Photos. Allow or Deny?”

You click Allow.

Step 3 — Authorization Server sends an Authorization Code

Google redirects you back to PrintMyPhotos with a short-lived authorization code:

https://printmyphotos.com/callback?code=AUTH_CODE_HERE&state=random-secure-string

This code is temporary — typically valid for just a few minutes.

Step 4 — Client exchanges code for Access Token (server-to-server)

PrintMyPhotos’s backend server sends the code to Google privately:

POST https://oauth2.googleapis.com/token
{
  "code": "AUTH_CODE_HERE",
  "client_id": "printmyphotos-123",
  "client_secret": "SECRET_KEY",
  "redirect_uri": "https://printmyphotos.com/callback",
  "grant_type": "authorization_code"
}

Step 5 — Authorization Server returns Access Token

Google responds with:

{
  "access_token": "ya29.a0AfH6SMBx...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "1//0g...",
  "scope": "https://www.googleapis.com/auth/photoslibrary.readonly"
}

Step 6 — Client uses Access Token to call Resource Server

PrintMyPhotos can now call Google Photos API using the token:

GET https://photoslibrary.googleapis.com/v1/albums
Authorization: Bearer ya29.a0AfH6SMBx...

Google Photos checks the token, confirms it is valid and has photos.readonly scope, and returns your photo albums.

The entire flow — from your perspective — happens in seconds. Behind the scenes, this multi-step process ensures your Google password never touches PrintMyPhotos’s servers.

Concept 4: OAuth 2.0 Grant Types — Four Different Flows 🔄

What is OAuth flexible enough to support? Multiple authorization flows — called grant types — for different use cases.

1. Authorization Code Flow The most secure flow. Used for web applications with a backend server. The access token is exchanged server-to-server, never exposed to the browser. This is the flow described in Concept 3.

• Best for: Web apps with a server-side component

2. Authorization Code Flow with PKCE (Proof Key for Code Exchange — pronounced “pixie”) An enhanced version of the Authorization Code Flow designed for apps that cannot safely store a client secret — mobile apps and single-page apps (SPAs).

• Best for: Mobile apps, React/Vue/Angular SPAs

3. Client Credentials Flow Used when there is no user involved — machine-to-machine communication. One server authenticates directly with the authorization server to get a token.

• Best for: Backend microservices, cron jobs, server-to-server API calls

4. Device Authorization Flow Used on devices with limited input capability — smart TVs, gaming consoles, IoT devices. The device shows a code; you enter it on your phone or computer.

• Best for: Smart TVs, CLI tools, devices without keyboards

Concept 5: Access Tokens and Refresh Tokens 🎫

Two critical pieces of what is OAuth in practice are access tokens and refresh tokens.

Access Token

An access token is a credential — typically a string — that the client uses to access protected resources on the resource server. Think of it as a temporary key card.

Key properties:

• Short-lived — typically expires in 1 hour (3600 seconds)
• Scoped — only allows access to what was requested
• Bearer token — whoever holds it can use it (so protect it carefully)
• Should be sent in the Authorization header: Bearer <token>

Refresh Token

When an access token expires, the client does not ask the user to log in again. Instead, it uses a refresh token — a longer-lived token — to quietly get a new access token from the authorization server.

Access Token expired
        ↓
Client sends Refresh Token to Authorization Server
        ↓
Authorization Server validates Refresh Token
        ↓
Issues new Access Token (and sometimes new Refresh Token)
        ↓
Client continues without user interruption

Key properties:

• Long-lived — can last days, weeks, or until revoked
• Only used with the authorization server — never sent to the resource server
• More sensitive than access tokens — store securely
• Can be revoked by the user at any time from their account settings

What is OAuth token lifetime strategy?

Short-lived access tokens + long-lived refresh tokens is the standard approach. If an access token is stolen, it is usable for only a short window. The refresh token stays safely server-side and is never exposed to the client in secure flows.

Concept 6: Scopes — Requesting Only What You Need 🎯

Scopes are one of the most important security features of what is OAuth. They define exactly what access the client is requesting — nothing more, nothing less.

When PrintMyPhotos redirects you to Google, it includes a scope parameter specifying exactly what it needs:

scope=https://www.googleapis.com/auth/photoslibrary.readonly

Google shows you exactly what the app is requesting: “Read your Google Photos library”. Not your emails. Not your contacts. Just photos, and only reading — not deleting or uploading.

Common OAuth scopes in the wild:

Google:

email              → Read email address
profile            → Read basic profile info
photos.readonly    → Read Google Photos
drive.readonly     → Read Google Drive files
calendar.events    → Read/write calendar events

GitHub:

repo               → Full access to repositories
read:user          → Read user profile data
user:email         → Read email addresses
gist               → Create and edit gists

What is OAuth scope best practice? Always request the minimum scopes your application actually needs — this is called the Principle of Least Privilege. Users are more likely to approve limited permissions, and a compromised token causes less damage if scopes are narrow.

Concept 7: OAuth vs OpenID Connect (OIDC) 🔍

This is one of the most commonly confused areas in what is OAuth discussions.

Remember — OAuth 2.0 is an authorization protocol. It answers: “What can this app do?” But it does not answer: “Who is this user?”

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds the ability to verify a user’s identity — answering: “Who is this user?”

When you click “Login with Google,” the flow involves both:

• OAuth 2.0 handles the authorization — giving the app permission to access your data
• OpenID Connect handles the authentication — confirming who you are

OIDC adds one key thing to the OAuth flow: an ID Token — a JWT (JSON Web Token) containing verified information about the user.

// ID Token payload (decoded JWT)
{
  "sub": "10769150350006150715113082367",
  "email": "rahul@gmail.com",
  "name": "Rahul Sharma",
  "picture": "https://...",
  "email_verified": true,
  "iss": "https://accounts.google.com",
  "exp": 1735689600
}

OAuth 2.0 vs OpenID Connect:

In practice, “Login with Google” uses both — OIDC for identity, OAuth 2.0 for resource access.

Concept 8: OAuth Security Best Practices 🛡️

Understanding what is OAuth also means knowing how to use it securely. OAuth, when misconfigured, can introduce serious vulnerabilities.

1. Always use HTTPS Every OAuth communication must happen over HTTPS. Never use OAuth over HTTP — the authorization code and tokens could be intercepted.

2. Use PKCE for public clients Any client that cannot safely store a secret — mobile apps, SPAs — must use PKCE (Proof Key for Code Exchange). This prevents authorization code interception attacks.

3. Validate the state parameter The state parameter prevents Cross-Site Request Forgery (CSRF) attacks. Always generate a random state value, store it in the session, and verify it matches when the callback arrives.

4. Request minimal scopes Request only the permissions your app actually needs. Never request broad scopes “just in case.”

5. Store tokens securely

• Access tokens: Keep in memory or httpOnly cookies — never in localStorage (vulnerable to XSS)
• Refresh tokens: Store in httpOnly, secure, sameSite cookies on the server

6. Validate redirect URIs strictly The authorization server must only redirect to pre-registered URIs. Open redirect vulnerabilities allow attackers to steal authorization codes.

7. Set appropriate token lifetimes

• Access tokens: 15 minutes to 1 hour
• Refresh tokens: Days to weeks, with rotation

8. Implement token revocation Provide users the ability to revoke access from their account settings. Handle revoked tokens gracefully in your application.