"Sign in with Google" looks like one click. Underneath, it's four distinct HTTP steps, and exactly one of them ever touches your server directly. This lab walks all four, in order, including the one step a browser never sees.
Theory 1 of 2
A code is not a token.
The value that comes back on the redirect after consent is an authorization code — short-lived, single-use, and worthless on its own. It proves the browser just completed consent; it does not prove your server is allowed to act as that user. The access token only exists after a second, separate step exchanges that code for it — server to server, never through the browser at all.
Theory 2 of 2
The exchange is the one step with no browser in the room.
Steps 1 and 2 happen in the user's browser, visible in the address bar. Step 3 — trading the code for a real access token — happens directly between your server and the provider's server, authenticated with your app's own client secret. The browser never sees it, never could forge it, and never needs to. This is the actual mechanism behind "your app never touches the user's password."
Before the Practicum
Four steps, one flow.
Same terminal as every other lab — click it, type or paste the command shown, Enter runs it.
Steps 1–2 simulate what the browser does automatically; step 3 is the real server-to-server exchange; step 4 is where it's actually used.
Real query parameter names throughout — client_id, redirect_uri, response_type=code, scope, state — the same ones a real Socialite integration generates.
Done
Four HTTP steps. One of them is the entire security model.
The redirect and the callback are visible to anyone watching browser traffic — that's fine, nothing sensitive travels there. The code-for-token exchange is the one step that's genuinely invisible to the browser, authenticated with a secret only your server holds, and it's the whole reason OAuth can promise "we never touch the user's password" and actually mean it.