“Sign in with Google” is OAuth. In simple language — OAuth 2.0 lets one app access some of our stuff on another service without ever seeing our password. It’s about delegated access, not login (that’s a common mix-up we’ll clear up at the end).
The problem OAuth solves
Say a photo-printing site wants our Google Photos. The bad old way: hand them our Google password. Now they can read our email, delete our account, everything — and we can’t take it back without changing the password.
OAuth fixes this. Instead of a password, the printing site gets a scoped, revocable token that says “read photos only”. No password shared, limited access, and we can revoke it anytime from our Google settings.
Think of it like a hotel key card. We don’t give the guest our master key — the front desk issues a card that only opens their room, only until checkout.
The four roles
Every OAuth flow has the same four players. Learn these names — interviewers ask directly.
- Resource Owner — us, the user who owns the data.
- Client — the app that wants access (the photo-printing site).
- Authorization Server — issues tokens after we approve (Google’s auth server).
- Resource Server — holds the data and honors the token (the Google Photos API).
Authorization Code flow (+ PKCE)
This is the main flow and the one to know cold. Here it is in plain steps.
Why the two-step dance (code, then token) instead of just handing over a token? The code comes back through the browser’s URL, which is a leaky place — logs, history, referer headers. The code alone is useless. The real token is fetched in a direct server-to-server call in step 4, out of the browser’s reach.
PKCE (Proof Key for Code Exchange, say “pixy”) plugs a hole for apps that can’t keep a secret — mobile and single-page apps. The client makes a random code_verifier, sends its hash (the code_challenge) in step 1, then reveals the original verifier in step 4. So even if someone steals the code, they can’t exchange it without the verifier. PKCE is now recommended for every client, not just public ones.
Access tokens vs refresh tokens
The token exchange usually gives us two.
- Access token — short-lived (minutes). Sent to the Resource Server on every call. If leaked, it expires fast.
- Refresh token — long-lived. Kept private by the client and used only to get a fresh access token when the old one expires — no need to bug the user again.
{
"access_token": "ya29.a0Af...",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "1//0gLo...",
"scope": "photos.read"
}The split is a blast-radius trade: the token flying around everywhere is short-lived, the powerful long-lived one stays hidden.
OIDC — the identity layer on top
Here’s the mix-up to clear: plain OAuth 2.0 is about authorization (access to resources), not logging you in. It never actually tells the client who you are.
OpenID Connect (OIDC) is a thin layer on top of OAuth that adds identity. Same Authorization Code flow, but the Auth Server also returns an ID token — a JWT with verified identity claims (sub, email, name). That’s what makes “Sign in with Google” a real login.
So the only difference in one line: OAuth gives an access token (what you can do), OIDC adds an ID token (who you are).
Interview soundbite
OAuth 2.0 grants delegated, scoped access without sharing a password. Four roles: resource owner, client, authorization server, resource server. The Authorization Code flow returns a short-lived code through the browser, then swaps it server-to-server for an access token — PKCE protects that exchange for public clients. Access tokens are short-lived, refresh tokens are long-lived and hidden. OAuth alone is authorization; OpenID Connect adds an ID token on top to give you authentication.