OAuth 2.0

OAuth 2.0 is a secure authorization framework that allows apps to access user data without needing passwords. The Authorization Code Flow is the most common and secure method, especially for apps with backend servers.

This guide explains the flow clearly and simply, using an example where the Zomato app uses Google for authentication and data access.

Key Roles in OAuth 2.0

Role	Simple Explanation	Professional Explanation
Resource Owner	The user who owns the data and grants access.	The entity that owns protected resources and authorizes client access.
Client Application	The app (Zomato) requesting data on user’s behalf.	The app requesting authorization and tokens to access resources securely.
Authorization Server	Google's server that authenticates users and issues tokens.	Server responsible for authenticating the resource owner and issuing tokens.
Resource Server	Google APIs hosting the user’s protected data (e.g., Google Drive).	Server hosting protected resources accessed with access tokens.

Note: The Resource Server is Google’s API that holds user data, not Zomato’s API.

OAuth 2.0 Authorization Code Flow: Step-by-Step Process

Step	From → To	What Happens	Details
1. (A→B)	Resource Owner → Client Application	User initiates login on Zomato app.	User clicks "Login with Google" button.
2. (B→C)	Client Application → Authorization Server	Redirect to Google login page.	User enters Google credentials on the login screen.
3. (C→B)	Authorization Server → Client Application	Google sends Authorization Code to app.	Temporary code sent via redirect URI, after user consent.
4. (B→C)	Client Application → Authorization Server	App exchanges Authorization Code for Access Token.	Backend POST request includes code and client credentials.
5. (C→B)	Authorization Server → Client Application	Access Token issued by Google to app.	Token used to access protected resources securely.
6. (B→D)	Client Application → Resource Server	App requests data from Google APIs using token.	Token sent in API requests as Bearer token.
7. (D→C)	Resource Server → Authorization Server	Google APIs verify token validity.	Valid tokens allow access; invalid requests are denied.

Key Concepts: Authorization Code vs Access Token

Aspect	Authorization Code	Access Token
What it is	Temporary code after user consents	Token granting access to user data
Purpose	Secure intermediate credential for token exchange	Used to access protected resources
When issued	After user login and consent	After client exchanges code for token
Visibility	Short-lived, sent via redirect	Stored and used by client app
Security Benefit	Prevents exposing access tokens in browser or URL	Used for authenticated API access

Summary

The user (Resource Owner) grants access to the app (Client).
Google (Authorization Server) authenticates and issues an Authorization Code.
The app exchanges this code for an Access Token.
The Access Token is used to access Google APIs (Resource Server).
Tokens are validated to ensure secure access.

This flow protects user credentials and enables secure, delegated data access.

📚 Resources & References

Here are some authoritative specifications and guides for OAuth 2.0 and related standards:

RFC 6749 – The OAuth 2.0 Authorization Framework
The primary specification for OAuth 2.0 — covers protocol roles, authorization flows, and token handling.
RFC 7591 – OAuth 2.0 Dynamic Client Registration Protocol
Describes methods for dynamically registering OAuth 2.0 clients with authorization servers.
OAuth 2.0 Overview – oauth.net
Industry-standard overview explaining concepts, best practices, and integration patterns.
OpenID Connect Core 1.0
An identity layer built on top of OAuth 2.0, enabling authentication and user identity sharing.
OAuth 2.1 (Draft)
The next evolution of OAuth, consolidating best practices and simplifying the standard.

OAuth 2.0 Explained: A Simple Overview

Table of contents