Flows, PKCE & OIDC vs. SAML

Authorization Code Flow

The recommended flow for most apps: the client receives a short-lived authorization code via browser redirect, then exchanges it for tokens in a direct back-channel request — keeping tokens off the browser's front-channel and away from URL fragments/history, unlike the now-deprecated Implicit flow.

PKCE for Public Clients

code_verifier = random_string()
code_challenge = base64url(sha256(code_verifier))

// authorization request includes code_challenge
// token exchange includes the original code_verifier — provider checks it matches

PKCE lets public clients (mobile apps, SPAs) that can't safely hold a client secret still use the Authorization Code flow securely — the verifier/challenge pair proves the token request came from the same client that started the flow, preventing a stolen authorization code from being redeemed by an attacker.

Refresh Tokens & Logout

Refresh tokens let a client obtain new access/ID tokens without forcing the user through interactive login again. Simply clearing local application state doesn't end a user's session at the provider — RP-Initiated Logout redirects to the provider's end-session endpoint to actually terminate it there too.

"Sign in with..." — OIDC in the Wild

"Sign in with Google/Microsoft/Apple" buttons are OIDC under the hood — a client redirects to the provider, receives back an ID token proving identity, and the aud claim protects against that token being misused by a different, unintended client application.

OIDC vs. SAML

OIDC's JSON/JWT-based, lightweight design and native support for public clients (via PKCE) fit mobile and single-page app architectures more naturally than SAML's XML/browser-form-based flows, which were designed around traditional server-rendered web apps — a major reason OIDC dominates newer application architectures while SAML remains entrenched in established enterprise SSO.