Authorization Code With PKCE Is the Default

For any client-side or mobile application, Authorization Code with PKCE is the only acceptable flow in 2026. Implicit flow is deprecated, password grant is deprecated, and client credentials are for server-to-server only. PKCE adds a code verifier/challenge pair that prevents authorization code interception even on public clients.

Server-side web apps with a backend can also use Authorization Code without PKCE, but adding PKCE is free defense in depth. The OAuth 2.0 for Native Apps RFC (8252) covers the requirements in detail.

Access Tokens Are Short-Lived; Refresh Tokens Rotate

Access tokens should expire in 5-15 minutes. Refresh tokens last longer (days to weeks) but should rotate on every use — a refresh request returns a new refresh token, the old one is invalidated. If an attacker steals a refresh token and uses it before the legitimate user does, the rotation breaks the attacker’s session.

Implement refresh token reuse detection: if the same refresh token is used twice, invalidate the entire token family and force re-authentication. Auth0, Clerk, and most modern auth providers handle this automatically.

OIDC Adds Identity to OAuth

OAuth 2.0 is authorization (what can this token do?). OIDC is authentication (who is this user?). OIDC layers ID tokens (signed JWTs containing user identity claims) on top of OAuth flows.

If you need to know who the user is — and 99% of web apps do — use OIDC, not raw OAuth. The ID token gives you a standard `sub` claim that is the stable user identifier. See our API design best practices for how identity flows through your downstream APIs.

Validate JWTs Properly

Most JWT vulnerabilities come from improper validation. Always verify the signature using the issuer’s public key (fetched from their JWKS endpoint), validate `iss`, `aud`, `exp`, `nbf`, and `iat` claims, and reject tokens with `alg: none`.

Use a maintained JWT library (jose, jsonwebtoken, golang-jwt) — never roll your own. Cache the JWKS but respect cache headers and refresh on unknown key IDs. The JWT specification (RFC 7519) defines the validation requirements.

Cookies Beat localStorage for Session Tokens

Storing access tokens in localStorage exposes them to XSS attacks. Storing them in HttpOnly Secure SameSite cookies limits the attack surface significantly. The token is sent automatically on requests to your origin and is invisible to JavaScript.

For SPA-to-API patterns, use cookie-based session management with the BFF (backend-for-frontend) pattern. The frontend talks to your BFF, the BFF holds the OAuth tokens and proxies authenticated requests downstream. This keeps tokens entirely server-side. Combine with our OWASP Top 10 risks guide for the complete security posture.

Wrap Up

OAuth and OIDC patterns done right give you scalable, standardized authentication that works across web, mobile, and API clients. Use Authorization Code with PKCE, short-lived access tokens with rotating refresh tokens, OIDC for identity, proper JWT validation, and HttpOnly cookies for session storage. Use a managed auth provider unless you have specific reasons not to — Auth0, Clerk, WorkOS, and Supabase Auth all implement these patterns correctly out of the box.

Frequently Asked Questions

Should I use a managed auth provider or roll my own?

Managed for almost everyone. The complexity of doing OAuth + OIDC + MFA + social login + enterprise SSO + compliance correctly is enormous. Reach for Clerk, Auth0, WorkOS, or similar unless you have a specific reason.

Are JWTs better than session cookies?

For stateless API authentication, JWTs are useful. For session management, cookies with server-side session storage are simpler and more secure. Use the right tool for the job — they are not competitors.

What about social logins?

Most managed providers handle Google/GitHub/Apple/Microsoft sign-in for you. If you build it yourself, each provider has slightly different OIDC quirks — budget time for that.

How do I handle MFA?

TOTP (Google Authenticator, Authy) is the baseline. WebAuthn/passkeys are the future and dramatically better UX. SMS as a fallback only — it is the weakest factor.

When should I use OAuth client credentials grant?

Only for server-to-server communication where there is no user. Backend services calling your APIs, scheduled jobs, integration credentials. Never for user-facing flows.

The post 7 Top OAuth and OIDC Patterns for Modern Web Apps appeared first on GTWebs.