Understanding OAuth 2.0: A Comprehensive Guide

OAuth 2.0 is the industry-standard protocol for authorization. It allows third-party applications to gain limited access to a user’s resources without exposing their credentials. Developed by the IETF OAuth Working Group, it has become the backbone of secure delegated access on the web.

From social login (like “Sign in with Google”) to accessing APIs in a secure way, OAuth 2.0 is used extensively by companies like Google, Facebook, GitHub, and Microsoft.

What is OAuth 2.0?

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account.

Key Features:

• Delegated access without sharing credentials.
• Token-based access control.
• Scalable for both web and mobile applications.
• Support for multiple grant types (flows).

Key Terminology

Example 1

OAuth 2.0 is like giving someone temporary and limited access to your stuff without giving them your password.

Imagine you want to let a photo printing app access your Google Photos, but you don’t want to share your Google username and password. With OAuth 2.0, you can let the app in just enough to print your photos — and only for a limited time.

Here’s how it works, simply:

• You go to the app and click “Connect to Google.”
• The app redirects you to Google to log in (you do this on Google’s website, not the app).
• You say “yes” to give the app permission.
• Google gives the app a special access token — like a visitor pass — that lets it only do what you allowed (like view your photos, but not delete them).
• You can take back this permission anytime from your Google settings.

So basically:

You stay in control, and the app never sees your password.

OAuth 2.0 Grant Types (Flows)

OAuth 2.0 defines several grant types for different use cases:

Authorization Code Grant (Most Secure)

Use Case: Web applications with server-side logic.

Flow:

• User logs in and approves access.
• Authorization code is sent to the client.
• Client exchanges the code for an access token.

Security: Keeps client credentials safe by never exposing them on the front-end.

Implicit Grant (Deprecated)

Use Case: Single-page applications (SPAs).

Flow:

• Access token is returned directly in the URL fragment.

This grant is considered insecure and deprecated by the OAuth 2.1 draft. Use Authorization Code + PKCE instead.

Client Credentials Grant

Use Case: Server-to-server communication.

Flow:

• Client authenticates with the authorization server and receives an access token.
• No user context—access is granted to the app itself.

Resource Owner Password Credentials (ROPC) Grant

Use Case: Trusted applications (not recommended).

Flow:

• User provides their credentials directly to the client, which is exchanged for a token.

Not recommended due to security risks. Avoid using in modern apps.

Device Authorization Grant

Use Case: Devices with limited input (e.g., TVs, IoT).

Flow:

• User logs in on another device to authorize access.

Authorization Code Grant with PKCE

Use Case: Public clients (e.g., mobile apps, SPAs).

Flow:

• App creates a code challenge and verifier.
• Authorization request includes the challenge.
• Token request includes the verifier.
• Server validates them to issue a token.

Prevents authorization code interception attacks.

Tokens in OAuth 2.0

Access Token

• Used to access protected resources.
• Short-lived and bearer in nature.

Refresh Token

• Used to obtain a new access token when the old one expires.
• Should be securely stored and not exposed in frontend clients.

Custom APIs

Basic Setup

Authorization Server

You need a service that can:

• Authenticate users
• Issue access tokens
• Validate those tokens

You can build this yourself or use services like:

• Auth0
• Keycloak
• Firebase Auth
• AWS Cognito

This server handles login and token issuing.

Your Custom API (Resource Server)

This is the backend/API you built. It will:

• Receive requests with access tokens (usually in the header).
• Validate the token before serving any data.

How It Works

Here’s a step-by-step flow:

• Client App (frontend, mobile app, etc.) wants to use your API.
• It redirects the user to the Authorization Server to log in.
• After login and approval, the Auth Server returns an access token.
• The Client App sends a request to your API like:

GET /user/profile
Authorization: Bearer <access_token>

• Your API checks the token:
  • Is it valid?
  • Has it expired?
  • Does it have permission (scopes)?

• If yes → return the data
• If not → return 401 Unauthorized

Final Architecture

Client App (frontend/mobile)
     |
     | → [Login or Authorization]
     ↓
Authorization Server  ←→  User DB
     |
     | → [Issues Access Token]
     ↓
Resource Server (API) ← Receives token, verifies, serves data

Conclusion

OAuth 2.0 is a powerful and flexible framework that enables secure authorization in modern applications. When implemented correctly, it significantly reduces the risk of credential theft while offering seamless integration between services.

However, its flexibility also makes it complex, so understanding each flow and its security implications is crucial. For most applications today, using Authorization Code with PKCE is the recommended approach.