Lesson 3 of 11 ·12 min read

1. What flow this actually is

The button says "Sign in with Google", but the machinery underneath is the OAuth 2.0 authorization code flow with PKCE, carrying OpenID Connect (OIDC) on top. The distinction is worth keeping straight:

• OAuth 2.0 answers "what is this app allowed to do?" (authorization). It delivers an access token.
• OpenID Connect is a thin layer on OAuth that answers "who is this user?" (authentication). It delivers an ID token, a signed JWT stating the user's identity.

Every "Sign in with X" button (Google, GitHub, Apple, Spotify) runs essentially this same dance. Learn it once and you have read them all. If you have worked through the free guide OAuth 2.0 in Python: The Authorization Code Flow Explained, this is the same flow seen from the app's side of the wire.

2. The full sequence at a glance

App              System browser         Google                 Your backend
 |                     |                    |                        |
 |--1 make PKCE pair,  |                    |                        |
 |   state, nonce      |                    |                        |
 |--2 open auth URL--->|                    |                        |
 |                     |--GET /auth ------->|                        |
 |                     |<--login page ------|                        |
 |                     |--credentials ----->|  (app never sees them) |
 |                     |<--redirect w/ code-|                        |
 |<-3 OS routes custom |                    |                        |
 |   scheme back to app|                    |                        |
 |--4 check state      |                    |                        |
 |--5 POST /token + code_verifier --------->|                        |
 |<----- access token + ID token (JWT) ----|                        |
 |--6 POST /auth/google  { id_token } ------------------------------->
 |                     |                    |<--fetch JWKS keys -----|
 |                     |                    |   verify sig/iss/aud/  |
 |                     |                    |   exp/nonce            |
 |<----- your API's access + refresh tokens -------------------------|
 |--7 store in Keychain/Keystore            |                        |
 |--8 Authorization: Bearer ... on every API call ------------------>

3. Before any user shows up: registration

The developer registers the app in the Google Cloud console and receives a client ID, and registers a redirect URI. On mobile that is a custom scheme like com.myapp:/callback, or better, an App Link / Universal Link (an https URL cryptographically bound to the app), which a malicious app cannot claim.

4. The flow, step by step

https://accounts.google.com/o/oauth2/v2/auth
  ?client_id=1234-abc.apps.googleusercontent.com
  &redirect_uri=com.myapp:/callback
  &response_type=code
  &scope=openid%20email%20profile
  &state=xyz123
  &code_challenge=E9Mel...
  &code_challenge_method=S256
  &nonce=n0nc3

com.myapp:/callback?code=4/0AX4Xf...&state=xyz123

POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

code=4/0AX4Xf...
&client_id=1234-abc.apps.googleusercontent.com
&redirect_uri=com.myapp:/callback
&grant_type=authorization_code
&code_verifier=dBjftJeZ4CVP...   <- the secret kept from step 1

{
  "access_token": "ya29.a0Af...",     // for calling Google's own APIs
  "id_token":     "eyJhbGciOi...",    // signed JWT: who the user is
  "refresh_token": "1//0gFt...",      // optional, for offline access
  "expires_in": 3599
}

POST /auth/google
{ "id_token": "eyJhbGciOi..." }

5. What each artefact is for

6. Why each defence exists

7. Variations worth knowing

• Web instead of mobile: same flow, but the redirect URI is an https URL on your domain, the exchange in step 5 happens server-side with a client secret, and the session usually ends up in an httpOnly cookie rather than stored tokens. PKCE is now recommended there too. This server-side variant is exactly what the OAuth guide builds in Python.
• Native sign-in SDKs: Google's Credential Manager (Android) and Sign in with Apple present a native sheet instead of a browser tab. Less visible ceremony, same artefacts underneath: you still end up with an ID token that your backend must verify identically from step 6 onward.
• "Sign in with GitHub/Spotify/etc.": the same authorization-code dance; some providers are OAuth-only (no OIDC ID token), in which case the backend calls the provider's /user endpoint with the access token to learn who logged in, then continues from step 7 unchanged.
• Magic links (the model endpoint51.com itself uses): a different first factor entirely (possession of an inbox instead of a Google account), but it converges at the same place. The backend confirms identity, then issues its own session credential. Steps 7–8 are universal; only steps 1–6 vary by provider.

Reviewed 4 August 2026.