OAuth 2.0 and OIDC Explained: The Complete Backend Guide
Demystify OAuth 2.0 and OpenID Connect — authorization flows, token types, PKCE, and how to implement secure auth in your backend services.
OAuth 2.0 confuses even experienced engineers because it’s an authorization framework, not a protocol — it defines roles and token exchange, but leaves implementation details open. Let’s fix the mental model.
The Core Vocabulary
- Resource Owner: The user who owns the data
- Client: Your application requesting access
- Authorization Server: Issues tokens (Auth0, Keycloak, Google)
- Resource Server: Your API that validates tokens
- Access Token: Short-lived credential for API access
- Refresh Token: Long-lived credential to get new access tokens
- ID Token: (OIDC only) JWT containing user identity claims
The Four OAuth 2.0 Flows
1. Authorization Code Flow — For Web Apps
The most secure flow. The authorization code is exchanged server-side, so access tokens never touch the browser.
2. Authorization Code + PKCE — For SPAs and Mobile
PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks. Mandatory for public clients (no client secret).
3. Client Credentials — Service-to-Service
No user involved. Machine-to-machine authentication.
4. Device Authorization — Smart TVs, CLIs
Used by: GitHub CLI, Google TV, AWS CLI.
OpenID Connect (OIDC) — Authentication on Top of OAuth
OIDC adds the openid scope and returns an ID Token (JWT) with user identity:
Key validation steps for ID Tokens:
Never manually decode a JWT without verifying the signature first.
Token Validation in Resource Servers
Common Security Mistakes
| Mistake | Fix |
|---|---|
Storing access tokens in localStorage |
Use HttpOnly cookies |
Not validating state parameter |
Always validate to prevent CSRF |
Accepting alg: none JWTs |
Explicitly whitelist allowed algorithms |
| Long-lived access tokens | Keep them short (15 min), use refresh tokens |
| Skipping PKCE for SPAs | PKCE is mandatory for public clients |
Trusting sub without iss |
Always validate both to prevent token confusion |
OAuth 2.0 and OIDC have a steep learning curve, but getting auth right is non-negotiable. Use a battle-tested library, validate every claim, and treat tokens like passwords.