Google OAuth Explained — From Cookies to “Continue with Google”

A beginner-friendly deep dive into how Google OAuth actually works under the hood.

What is Authentication?

Before we talk about OAuth, we need to understand what authentication actually means.

Authentication is simply answering the question: “Who are you?”

When you log into any app, the app needs to verify your identity before giving you access to your data. This is authentication. It is different from authorization, which answers a different question: “What are you allowed to do?”

Authentication → proving who you are
Authorization → deciding what you can access

When you log into Gmail, Google first checks who you are (authentication), and then decides what you can access (authorization — your inbox, not someone else’s).

The Core Problem Authentication Solves

HTTP — the protocol your browser uses to talk to servers — is stateless. Every request is completely independent. The server has no memory of previous requests.

So when you load gmail.com/inbox, the server has no idea who you are. It sees an anonymous request. Authentication is the mechanism that attaches identity to requests.

The naive solution would be to send your username and password with every single request. That is obviously terrible. So instead, after you prove your identity once, the server gives you a token — a signed piece of data you attach to future requests. The server can verify the token without you re-entering your password every time.

How Passwords Actually Work

The most common authentication mechanism is a shared secret — something only you and the server both know. A password is the classic example.

When you register:

You tell the server: "my password is abc123"
Server stores:       hash(abc123) = $2b$10$xyz...   ← not the password itself

When you log in:

You send:        abc123
Server computes: hash(abc123) = $2b$10$xyz...
Server checks:   does this match what I stored? → yes → you are verified

The server never stores your actual password — it stores a one-way hash. Even if the database leaks, attackers cannot reverse the hash back to your password easily.

What is OAuth?

OAuth solves a specific problem: what if you want to prove your identity to App B, but using your identity from App A?

For example — you want to log into a new app called xyz, but you do not want to create yet another username and password. You already have a Google account. Can xyz just ask Google “hey, is this person who they say they are?” and trust the answer?

That is exactly what OAuth does. It is a protocol that lets one service (Google) vouch for your identity to another service (xyz) — without xyz ever seeing your Google password.

The key insight: xyz never learns your Google password. Google handles the login, then tells xyz “yes, this is [email protected], here is a token proving it.”

The Hotel Analogy

Imagine a hotel analogy to understand the OAuth flow:

You arrive at a hotel (xyz) and want to get in
The hotel says “we do not manage IDs ourselves — go to the front desk agency across the street (Google)”
You walk to Google and show your passport (your Google password)
Google stamps a ticket and gives it to you
You bring the ticket back to the hotel
The hotel calls Google to verify the ticket is real
Google confirms it — the hotel lets you in

xyz never saw your passport. It just trusted the ticket Google stamped.

The OAuth Flow Step by Step

Here is what technically happens when you click “Continue with Google”:

1. You click "Continue with Google" on xyz
2. xyz redirects your browser to:
   https://accounts.google.com/oauth/authorize
     ?client_id=xyz-client-id
     &redirect_uri=https://xyz.com/callback
     &scope=email profile
     &response_type=code

3. Your browser navigates to accounts.google.com
   (Google's central authentication domain)
4. Google checks: do I already have a session cookie for this user?
   → Yes → skip the password prompt
   → No  → show the password form
5. Google asks: "Do you want to give xyz access to your profile?"
   → You click Allow
6. Google redirects back to xyz with a short-lived code:
   https://xyz.com/callback?code=4/abc123
7. xyz backend sends that code to Google:
   "Is this code valid?"
8. Google responds: "Yes, and here is the user's email, name, and avatar"
9. xyz creates or finds the user in its database
10. xyz issues its own JWT and logs you in

What is a JWT?

After verifying your identity, the server needs a way to remember you across future requests without checking your password every time. This is where JWT (JSON Web Token) comes in.

A JWT looks like this:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIxMjMifQ.abc123signature

It has three base64-encoded parts separated by dots:

HEADER . PAYLOAD . SIGNATURE

{                    {                    hmac(header + payload,
  "alg": "HS256"       "userId": "123",     secretKey)
}                      "exp": 1234567890
                     }

The payload contains your user ID, email, and when the token expires. The signature is a cryptographic hash that proves the token was not tampered with. If anyone modifies the payload, the signature breaks and the server rejects it.

Your browser stores this JWT and sends it with every API request:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

The server verifies the signature, reads the payload, and knows who you are — without touching the database on every request.

The Role of Cookies

Here is something that confuses most beginners: when you click “Continue with Google”, you often never see a password prompt. Why?

Because you are already logged into Google.

When you logged into Gmail months ago, Google stored a long-lived session cookie in your browser:

HTTP Header from Google's server:
Set-Cookie: session=abc123xyz; Domain=accounts.google.com; HttpOnly

Your browser stores that cookie against the domain accounts.google.com.

Now browsers have one fundamental built-in rule:

“Whenever I make a request to a domain, automatically attach all cookies I have stored for that domain.”

So when “Continue with Google” redirects you to accounts.google.com, your browser automatically sends that stored cookie. Google sees it, recognises you, and skips the password prompt entirely.

accounts.google.com — The Single Source of Truth

You might have noticed that Gmail lives at gmail.com and YouTube lives at youtube.com. These are completely different domains. So how does one Google login cover all of them?

Google uses a central authentication domain: accounts.google.com.

Every Google product — Gmail, YouTube, Docs, Gemini, Drive — redirects to accounts.google.com to verify your identity. None of them check it themselves.

accounts.google.com cookie  →  your master Google identity
        ↓
youtube.com                 →  trusts accounts.google.com
gmail.com                   →  trusts accounts.google.com  
docs.google.com             →  trusts accounts.google.com
xyz (via OAuth)             →  trusts accounts.google.com

This is called Single Sign-On (SSO) — one login gives you access everywhere.

Why You Never See accounts.google.com During OAuth

When you click “Continue with Google” on a third-party app, your browser does briefly visit accounts.google.com — but it happens so fast you never notice.

You click "Continue with Google"
        ↓
Browser navigates to accounts.google.com   ← this happens, invisibly
        ↓
Google sees your session cookie
        ↓
Google immediately redirects back to the app
        ↓
You are logged in — feels instant

You can catch it happening. Open Chrome DevTools → Network tab → click “Continue with Google” → you will see the request to accounts.google.com right there in the list.

The Complete Mental Model

Your Google password (entered once, long ago)
        ↓
accounts.google.com session cookie (stored in browser)
        ↓
OAuth: Google vouches for your identity to xyz
        ↓
xyz issues its own JWT
        ↓
JWT used for all future requests to xyz

Every layer is just a token saying “I already verified the thing below me.” The password is still the root of everything — it is just cached several layers deep so you do not have to type it every time.

Authentication Factors — Beyond Passwords

Passwords are just one way to prove identity. There are three categories:

Factor What it means Example Something you know A secret only you know Password, PIN Something you have A physical or digital object Phone, security key Something you are A biological trait Fingerprint, Face ID

Two-factor authentication (2FA) combines two of these — making it much harder for an attacker who only has your password to get in.

Why Use OAuth Instead of Building Your Own Auth?

If you are building an app, you could handle authentication yourself — store passwords, write login logic, manage sessions. But OAuth offloads all of that to a trusted provider.

Benefits of OAuth:

You never store passwords — no risk of your database leaking them
Users trust Google more than they trust your new app
You get the user’s verified email and profile for free
You skip building password reset, email verification, and session management

The tradeoff:

You depend on Google staying online and maintaining their OAuth service
If Google revokes your OAuth credentials, your login breaks

For most apps, the benefits far outweigh the tradeoffs.

Summary

Authentication is proving who you are
Passwords are shared secrets — servers store a hash, not the password itself
OAuth lets one service (Google) vouch for your identity to another (xyz)
Cookies are how browsers remember your identity across requests — sent automatically by the browser to matching domains
accounts.google.com is Google’s central identity domain — the single source of truth for all Google products
JWT is a signed token issued after login so you do not re-authenticate on every request
SSO means one login (your Google account) silently logs you into many apps

The next time you click “Continue with Google”, you will know exactly what is happening under the hood — a millisecond trip to accounts.google.com, a cookie check, and a chain of trust flowing all the way back to the password you entered months ago.

Connect with me : Linkedin

Google OAuth Explained — From Cookies to “Continue with Google” was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.