patternCriticalpending
OAuth 2.0 / OIDC flow selection guide
Viewed 0 times
oauthoidcpkceauthorization codeclient credentialstoken storage
Problem
Need to choose the right OAuth 2.0 flow for different application types (SPA, mobile, server-side, machine-to-machine).
Solution
Flow selection by application type:
Server-side web app (Next.js, Django, Rails):
Authorization Code Flow
SPA / Mobile app:
Authorization Code Flow + PKCE
Machine-to-machine (cron jobs, microservices):
Client Credentials Flow
NEVER use:
Token storage:
Server-side web app (Next.js, Django, Rails):
Authorization Code Flow
1. Redirect user to /authorize
2. User logs in, consents
3. Server receives code via callback URL
4. Server exchanges code for tokens (server-to-server)
5. Tokens stay on server, never exposed to browserSPA / Mobile app:
Authorization Code Flow + PKCE
1. Generate code_verifier (random string)
2. Generate code_challenge = SHA256(code_verifier)
3. Redirect to /authorize with code_challenge
4. After login, exchange code + code_verifier for tokens
5. No client_secret needed (can't store secrets in SPA/mobile)Machine-to-machine (cron jobs, microservices):
Client Credentials Flow
POST /token
grant_type=client_credentials
client_id=xxx
client_secret=yyy
scope=api:readNEVER use:
- Implicit flow (deprecated - tokens in URL fragment)
- Resource Owner Password flow (shares credentials)
Token storage:
- Server-side: encrypted session/database
- SPA: in-memory (not localStorage!)
- Mobile: OS keychain (iOS Keychain, Android Keystore)
Why
Using the wrong OAuth flow creates security vulnerabilities. PKCE prevents authorization code interception on public clients. Implicit flow leaks tokens in browser history.
Gotchas
- SPAs cannot securely store client_secrets - use PKCE
- Refresh tokens in SPAs should use rotation + sender-constrained tokens
- Always validate the state parameter to prevent CSRF
Context
Implementing authentication in any application type
Revisions (0)
No revisions yet.