Sign in with Google, explained
One button, a carefully choreographed round trip. Follow the OAuth authorization code flow all the way to the tokens, and see why the app you sign into never once sees your password.
You click Sign in with Google
You click one button instead of inventing yet another password. What follows is a choreographed exchange built around a single rule: the app you are signing into never sees your Google password, not once, not ever.
App builds the authorization request
The app assembles a request naming itself with a public client identifier, listing exactly what it wants access to, and pinning the address it expects you back at. It also attaches a random string called state.
A one time secret and its hash
It then invents a one time secret, hashes it, and sends only the hash. This trick is called proof key for code exchange, and it makes a stolen authorization code worthless to anyone without the original secret.
Browser redirected to Google
Your browser is sent to Google carrying all of that in the address bar. Notice what is not in it: no password, no account name, nothing about you at all. So far the app has learned absolutely nothing.
You sign in on Google's own page
Now you are on Google's own domain, with Google's own certificate showing. This is the entire point of the design. You type your password into Google and only Google, which is why checking that address bar matters.
The consent screen lists the scopes
The consent screen spells out the scopes being asked for: see your email address, read your calendar, upload to your drive. A well behaved app requests the smallest set it can work with, and you can always refuse.
Sent back with a one time code
Approve, and Google bounces your browser back to the exact address registered in advance, carrying a short lived authorization code. That code stays valid for only a few minutes and may be redeemed exactly once.
The state value is checked
The app first compares the returned state value with the one it sent out. If they differ, someone has tried to graft their own login onto your session, and the whole request is thrown away without hesitation.
Server calls Google directly
Then the important part happens out of sight. The app's own server calls Google directly, presenting the code, its client secret and the original one time secret. Your browser is not involved and cannot interfere.
Google issues the tokens
Google checks all three, confirms the code has not been redeemed already, and only then answers with tokens. Because this leg never touches your machine, an attacker holding a copy of the code still has nothing usable.
Access, identity and refresh tokens
Three things come back. An access token, usually good for an hour, that opens specific doors. An identity token describing who you are. And often a refresh token, which quietly buys fresh access tokens for months.
Identity token signature verified
The identity token is a signed statement. The app verifies the signature against Google's published keys, checks that the token was issued for itself and has not expired, and only then believes the email address inside.
The app creates its own session
Now the app finally creates its own session for you. What it stores is a Google account identifier, not a password, so there is simply no password of yours sitting in that company's database waiting to leak.
Token used within its scopes
From here the access token travels with every request, and Google enforces the scopes you agreed to. Ask for a calendar you never granted and the answer is a flat refusal, no matter how valid the token is.
You can revoke access any time
The best part is the exit. One page in your Google account lists every app you have ever connected, and revoking one kills its tokens straight away. Try doing that with a password you reused across ten sites.
Watch it explain itself
Every step above is narrated aloud. Play it, or open it in the editor and make it yours — no account needed.