OAuth 2.0: Flow, Demystified

Ever clicked “Sign in with Google” and wondered what sorcery happens behind the scenes? Let’s break it down, no jargon soup, just the real flow.

The Problem OAuth Solves

Imagine you’re building an app. Your frontend needs to talk to your backend. How does the backend know who’s making the request?

The naive approach: Send your username and password with every request. This goes in your POST payload, travels to the backend, gets authenticated. Simple, right?

Original Naive Approach

Wrong. This is a security nightmare. Your credentials are floating around in network requests, vulnerable to interception, man-in-the-middle attacks, and a dozen other exploits.

The OAuth approach: Let a trusted third party (like Google) vouch for you. No passwords flying around. Just tokens.

So this means, you browsers connects to your backend, which can now return you data by querying its corresponding database, but without requiring your username and password on every api call you make by replacing this with the JWT that has been issues after confirming your details. This token is short lived.

Its like a third party service communicates to your backend for you from your end and backend considers it that its you. This prevents your information to be floating arounding in web!

The Complete Flow

Let me walk you through what actually happens when you click that “Sign in with Google” button.

Step 1: The Click

You’re on an app. You see “Sign in with Google.” You click it.

The app redirects you to Google’s authentication page. This URL contains something called a client ID — a unique identifier that tells Google which app is asking for access.

Step 2: Google’s Permission Screen

Google shows you a screen: “Allow [App Name] to access your account?”

You see what permissions the app is requesting. You click “Allow.”

Step 3: The Authorization Token

Google sends a payload back to your browser containing an authorization token. This token is essentially Google saying, “This person clicked ‘Allow’ on our page.”

Think of it as a claim ticket. It proves you went through Google’s gate, but it’s not the actual access pass yet.

Step 4: Backend Takes Over

Your frontend sends this authorization token to your backend.

Now here’s where it gets interesting. The backend has two secrets that were configured during OAuth setup:

• Client ID (same one from Step 1)
• Client Secret (only the backend knows this)

The backend makes a request to Google’s API, sending:

• The authorization token (from the frontend)
• The client ID
• The client secret

Step 5: Google Validates Everything

Google checks:

• Is this client ID legitimate?
• Does the client secret match?
• Is this authorization token valid and unused?

If everything checks out, Google responds with:

{
  "access_token": "...",
  "id_token": "...",
  "expires_in": 3600
}

The id_token is a JWT (JSON Web Token)—a unique identification of the user.

Step 6: Fetching User Details

The backend uses the access_token to call another Google endpoint. This time, Google returns the actual user information: email and name.

Get Sanshray’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Why does this work? Because when you clicked your email back in Step 1, Google created an internal mapping:

{sanshray@gmail.com : <authorization_token>}

Every token generated afterward is linked back to this original mapping. The chain of trust is maintained throughout.

Step 7: Backend Creates Your Session

The backend now has your email and name, authenticated by Google. It checks the database:

• User exists? Great, log them in.
• New user? Create an account.

Finally, the backend generates a Bearer authentication token — your app’s own token, issued by your own backend, valid for your own API calls.

Step 8: Normal Operations Resume

From here on out, your frontend includes this bearer token in every request header. The backend trusts it because it issued it, and it only issued it after Google confirmed your identity.

Final workflow diagram

Why This Is Better

Think about what we avoided:

1. No credentials in transit: Your password never leaves Google’s servers
2. No credential storage: The app never sees or stores your password
3. Token expiration: Even if a token is compromised, it expires
4. Single point of authentication: Google handles the security-critical parts

Instead of sending username + password with every request, you send a single bearer token that:

• Was issued by your backend
• Only after Google confirmed your identity
• Expires after a set period

Quick Note on “Sign in with Google” vs “Sign in with Gmail”

These sound similar but can be different implementations. “Sign in with Gmail” might use Firebase Auth, which wraps Google OAuth under the hood. Same underlying mechanism, different abstraction layer. But that’s a topic for another day.

The TL;DR

1. You click “Sign in with Google”
2. Google asks if you trust the app
3. You say yes, Google gives you a claim ticket (authorization token)
4. Your app’s backend takes that ticket, proves it’s legitimate with its secret keys
5. Google gives the backend a real access token
6. Backend uses that to get your email/name from Google
7. Backend creates its own token for you
8. You use that token for all future requests

No passwords exposed. No credentials stored. Just a chain of verified tokens.

That’s OAuth 2.0 in practice. Next time you click that “Sign in with Google” button, you’ll know exactly what’s happening behind the scenes.

Writer

Sanshray Singh Langeh