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

  1. What is OAuth 2.0?
  2. Key Players in the Flow
  3. The Full OAuth 2.0 Flow (Step-by-Step)
  4. How Authorization Server Knows the User
  5. Real-World Analogy
  6. Diagram: OAuth 2.0 Authorization Code Flow
  7. 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).

  1. A friend (client) says, "Can I borrow your book?"
  2. You (user) walk to the library, show ID, and say, "Yes, allow this person to borrow my copy of Book A."
  3. The librarian (Auth Server) gives the friend a pass/token with your approval.
  4. 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