SSO & OAuth

You clicked "Sign in with Google." Five redirects, one authorization code, a token exchange, and a signed JWT later, BlogApp knows you are you. Without ever seeing your password. Watch it happen, step by step.

Scenario

Browser / User you

Relying App blog.example.com

Identity Provider accounts.google.com

Ready

Pick a scenario and click Play flow. Each step is a real HTTP redirect or API call. Click any step card to see the actual request and response.

HTTP exchange

ID Token decoded

Signed JWT from accounts.google.com

Three base64url pieces, separated by dots, signed with Google's RS256 key

Header { "alg": "RS256", "kid": "f5f4bf46e52b31d9b", // which Google key signed this "typ": "JWT" }

Payload (claims) { "iss": "https://accounts.google.com", // issuer "sub": "112233445566778899001", // your unique id at Google "aud": "987654321-abc.apps.googleusercontent.com", // BlogApp's client_id "email": "[email protected]", "email_verified": true, "name": "Your Name", "picture": "https://lh3.googleusercontent.com/...", "iat": 1744732800, // issued at "exp": 1744736400 // expires in 1 hour }

Signature // RSA-SHA256 signature over base64url(header) + "." + base64url(payload) // BlogApp verifies this with Google's public key from: // https://www.googleapis.com/oauth2/v3/certs (JWKS) // If signature matches and aud == client_id and exp not past, identity proven. 0xBKAbrS...QoW3mRg

What just happened

Nerd tip

PKCE killed the client secret for SPAs and mobile. A single-page app running in the browser has nowhere safe to store a client secret. Someone can always open DevTools and read the source. PKCE (Proof Key for Code Exchange, RFC 7636) replaced the secret with a one-time code_verifier: a random string the app generates, hashes into a code_challenge, sends the challenge with the auth request, then sends the plaintext verifier when exchanging the code for tokens. The IdP checks the hash matches. If an attacker intercepts the code, they do not have the verifier, so they cannot redeem it.

Nerd tip

OAuth is authorization. OIDC is authentication. OAuth 2.0 alone answers "can this app call the Google Calendar API on your behalf?" It does not answer "who is the user?" OIDC is a thin layer that adds exactly that: a standardized ID Token (JWT) with iss, sub, aud, and optional profile claims. When you click "Sign in with Google" you are using OIDC, not raw OAuth. People say OAuth but almost always mean OIDC.

Nerd tip

The state parameter prevents CSRF. Before redirecting you to Google, the app generates a random state and stores it in your session. Google echoes it back in the callback URL. The app checks the callback's state matches the stored one. Without this, an attacker could craft a malicious callback link and make your browser complete their login instead of yours. Missing state validation is one of the most common OAuth CVEs of the last decade.