Overview
OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user resources without exposing credentials, while OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that adds authentication. Together, they form the foundation of modern identity architecture—powering "Login with Google," API authorization, and enterprise SSO. OAuth 2.0 defines how clients obtain access tokens to call APIs on behalf of users (or themselves), while OIDC adds the ID Token that tells the client who the user is. Understanding these protocols is essential for any IAM practitioner, as they're embedded in virtually every modern application, mobile app, and API. Getting the implementation wrong—using deprecated flows, misconfiguring token validation, or neglecting token security—creates significant vulnerabilities.
Architecture & Reference Patterns
Pattern 1: Authorization Code Flow with PKCE
The recommended flow for web applications and mobile apps. The client redirects the user to the authorization server, receives an authorization code, and exchanges it for tokens using PKCE (Proof Key for Code Exchange) to prevent code interception attacks. ID Token provides user identity, Access Token provides API authorization, Refresh Token enables long-lived sessions. This is the default choice for new applications.
Pattern 2: Client Credentials Flow
For machine-to-machine (M2M) authentication where no user is involved. The client authenticates directly with its client ID and secret (or certificate) to obtain an access token. Used for service accounts, background jobs, and server-to-server API calls. No user context means no ID Token—just access tokens scoped to the client's permissions.
Pattern 3: Backend for Frontend (BFF) Pattern
For single-page applications (SPAs), the BFF pattern moves token handling to a backend service. The SPA communicates with its BFF using session cookies, while the BFF handles OAuth flows and stores tokens securely. Avoids exposing tokens to browser JavaScript, improving security. Recommended over implicit flow or public client token storage.
Pattern 4: Token Exchange and Federation
When services need to call downstream APIs on behalf of users, token exchange (RFC 8693) allows a service to exchange its access token for a new token with different scopes or audience. Enables secure delegation in microservices architectures without token forwarding. Also used for cross-realm federation where tokens from one authorization server need to be accepted by another.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| OAuth flow for web apps | Auth Code with PKCE, Implicit (deprecated) | Auth Code with PKCE—always | Implicit flow is deprecated; if you have it, migrate away |
| OAuth flow for SPAs | Auth Code + PKCE (public client), BFF pattern | BFF pattern for high-security; Auth Code + PKCE for simpler apps | Public client tokens in browser are theft targets—consider BFF |
| OAuth flow for mobile | Auth Code + PKCE with system browser | Auth Code + PKCE using AppAuth libraries | Embedded WebViews are deprecated; use system browser |
| Token storage (client-side) | Memory, localStorage, sessionStorage, cookies | Memory preferred; HttpOnly cookies via BFF | localStorage is vulnerable to XSS; memory clears on refresh |
| Access token lifetime | Short (5-15 min), medium (1 hour), long (24+ hours) | Short (15 minutes or less) with refresh tokens | Longer lifetimes increase compromise window; balance with UX |
| Refresh token rotation | Disabled, enabled, enabled with reuse detection | Enabled with reuse detection | Rotation limits damage from token theft; reuse detection catches replay |
| Token format | Opaque reference tokens, self-contained JWT | JWT for distributed validation; reference for revocation control | JWTs can't be revoked instantly—use short lifetimes |
Implementation Approach
Phase 0: Discovery
Inputs: Application inventory, current authentication methods, API landscape, security requirements Outputs: Application categorization by OAuth flow requirements, client type analysis (confidential, public, M2M), scope requirements mapping, current token handling assessment
Phase 1: Design
Inputs: Discovery outputs, security standards, authorization server capabilities Outputs: OAuth flow selection per application type, scope naming conventions, token lifetime policies, client registration standards, token binding requirements, authorization server configuration
Phase 2: Build & Integrate
Inputs: Design documents, authorization server access, test applications Outputs: Authorization server configured with policies, sample applications demonstrating each flow, client registration process established, token validation libraries/SDKs available, developer documentation published
Phase 3: Rollout
Inputs: Tested configuration, prioritized application list, developer support resources Outputs: Applications migrated to OAuth/OIDC in priority order, legacy authentication deprecated, developer training completed, monitoring and alerting operational
Phase 4: Operate
Inputs: Production OAuth infrastructure, monitoring dashboards, security scanning Outputs: Client registration managed through governed process, scope management and review, token security monitored (theft detection), regular security assessment of flows and configurations
Deliverables
- OAuth/OIDC architecture document with flow selection guidance
- Authorization server configuration standards
- Client registration policy and procedures
- Scope naming conventions and management process
- Token lifetime and security policy
- Developer guide with code samples per language/framework
- Token validation library or SDK recommendations
- Security checklist for OAuth/OIDC implementations
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Authorization code interception | L | H | OAuth security assessments, pen test findings | PKCE for all auth code flows, state parameter validation |
| Token theft via XSS | M | H | Security scans finding XSS, token appearing from unusual clients | BFF pattern, HttpOnly cookies, Content Security Policy |
| Refresh token theft enables long-term access | M | H | Tokens used from unusual locations, anomalous API patterns | Refresh token rotation, binding, reuse detection, short refresh lifetimes |
| Misconfigured redirect URIs allow token theft | M | H | Security audit findings, pen test results | Strict redirect URI validation, no wildcards, exact match only |
| Scope creep grants excessive permissions | M | M | Access reviews finding over-privileged clients | Minimal scope grants, regular scope audits, scope approval workflow |
| Token validation bypass | M | H | Security testing findings, unauthorized access | Standardized validation libraries, signature verification, audience/issuer checks |
KPIs / Outcomes
- OAuth/OIDC adoption: Percentage of applications using modern flows (target: 100% for new apps)
- Deprecated flow usage: Track and eliminate implicit flow and password grant usage
- Token security incidents: Track token theft/misuse incidents (target: zero)
- Developer adoption: Time to integrate OAuth for new applications (target: under 1 day with SDK)
- Authorization server availability: Target 99.95% uptime
- Token validation errors: Monitor and investigate validation failures