Ever wondered how the Authorization Server knows whose data the client app is asking for? In this blog, we’ll walk through the complete OAuth 2.0 authorization flow with simple explanations, diagrams, and real-world analogies to answer that question.
📘 Table of Contents
- What is OAuth 2.0?
- Key Players in the Flow
- The Full OAuth 2.0 Flow (Step-by-Step)
- How Authorization Server Knows the User
- Real-World Analogy
- Diagram: OAuth 2.0 Authorization Code Flow
- Conclusion
💡 What is OAuth 2.0?
OAuth 2.0 is an authorization framework that allows a third-party application (the client) to get limited access to a user's data without needing their password.
Example:
"Allow Spotify to access your Google Contacts."
OAuth makes this possible — securely, and with user consent.
🧑🤝🧑 Key Players in the Flow
Role | Description |
---|---|
Resource Owner | The user whose data is being accessed. |
Client | The third-party app requesting access (e.g., Spotify, Zoom). |
Authorization Server | Verifies user identity, gets consent, and issues tokens. |
Resource Server | Hosts the actual data (like Google Contacts, Facebook photos). |
🧭 The Full OAuth 2.0 Flow (Step-by-Step)
Let’s walk through the Authorization Code Grant Flow, the most common and secure flow.
🔁 Step 1: Client Redirects User to Authorization Server
GET /authorize?response_type=code
&client_id=client123
&redirect_uri=https://clientapp.com/callback
&scope=read_profile
&state=abcXYZ
- The client app sends the user to the Authorization Server.
- It includes a scope (what it wants to access), a redirect URI, and a state (for CSRF protection).
🔐 Step 2: User Logs In
The user logs in to the Authorization Server (e.g., Google or Facebook login page).
✅ Now the server knows who the user is — identity is verified!
📜 Step 3: User Grants Consent
The user is shown a consent screen:
"This app wants to access your profile and contacts. Allow?"
If the user approves, the server knows:
- Who the user is ✅
- What they are allowing ✅
- Which app is asking ✅
📦 Step 4: Authorization Server Sends Authorization Code
GET https://clientapp.com/callback?code=abc123&state=abcXYZ
The server sends back a temporary code to the client via the redirect URI.
🛂 Step 5: Client Exchanges Code for Access Token
POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=abc123
&redirect_uri=https://clientapp.com/callback
&client_id=client123
&client_secret=secret456
Now the client app sends the code (and its credentials) to get an access token.
🎟️ Step 6: Authorization Server Issues Access Token
The access token is issued and returned to the client.
This token represents:
- The user
- The granted scopes
- The client
🔓 Step 7: Client Accesses User’s Data Using Access Token
GET /userinfo
Authorization: Bearer eyJhbGciOi...
The client uses the token to fetch data from the Resource Server.
The Resource Server validates the token and responds with user-specific data.
🧠 How Authorization Server Knows the User?
➡️ Because the user logs in during the OAuth flow.
➡️ The access token is tied to that user’s identity and permissions.
➡️ So, whenever the client uses the token, the server knows:
- Whose data is being accessed
- What data is allowed (based on scopes)
- Which app is requesting it
🏢 Real-World Analogy
Imagine you're visiting a library (Authorization Server).
- A friend (client) says, "Can I borrow your book?"
- You (user) walk to the library, show ID, and say, "Yes, allow this person to borrow my copy of Book A."
- The librarian (Auth Server) gives the friend a pass/token with your approval.
- The friend goes to the shelf (Resource Server) and uses the pass to get the book.
🎯 The librarian knows who the book belongs to because you showed up and authorized it.
🧭 Diagram: OAuth 2.0 Authorization Code Flow
sequenceDiagram
participant User
participant Client
participant AuthServer
participant ResourceServer
Client->>User: Redirect to login/consent
User->>AuthServer: Login and grant consent
AuthServer->>User: Redirect back with code
User->>Client: Sends code
Client->>AuthServer: Exchange code for token
AuthServer-->>Client: Access token
Client->>ResourceServer: Request data with token
ResourceServer-->>Client: Respond with user data
✅ Conclusion
- The Authorization Server knows whose data is being accessed because the user logs in and grants permission.
- The access token contains everything the Resource Server needs to serve the right data — securely and with consent.
- OAuth 2.0 lets users stay in control of their data while allowing apps to access what’s necessary.
If you want to go deeper, we can explore:
- Refresh Tokens
- OAuth with Spring Boot
- OAuth vs OpenID Connect
- Role of JWT tokens in OAuth
OAuth 1.0 Flow Link
Jwt vs Oauth 1.0 Vs OAuth 2.0 Vs OpenId Link