Web Security – GTWebs

7 Top OAuth and OIDC Patterns for Modern Web Apps

Spida C — Thu, 04 Jun 2026 16:00:00 +0000

OAuth and OIDC patterns are the standard answer for authentication in 2026, but the implementations are full of footguns that even experienced teams trip over. The original OAuth 2.0 spec is intentionally flexible; the security best practices have evolved significantly since 2012. The teams getting auth right in production are following the current OAuth 2.1 + OIDC + PKCE conventions and avoiding the deprecated patterns that still show up in tutorials. Here is what to actually implement.

Authorization Code With PKCE Is the Default

Photo by Airam Dato-on on Pexels

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.

Photo by Boskampi on Pixabay

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.

7 Critical OWASP Top 10 Risks Every Web Team Must Address

Spida C — Tue, 12 May 2026 16:00:00 +0000

OWASP Top 10 risks are not new threats — they are the old threats that keep working because teams keep making the same mistakes. The 2021 list (still the current major version as of 2026, with 2025 updates pending) shifted Broken Access Control to the top spot because it remains the #1 source of real-world breaches. If your security review starts and ends with “we run Snyk on dependencies,” you are missing most of the actual attack surface. Here is what to focus on.

Broken Access Control Is Still Number One

Photo by Altamart on Unsplash

The most common breach pattern is shockingly mundane: a logged-in user changes an ID in a URL and gets data they should not see. Insecure direct object references (IDOR), missing authorization checks on API endpoints, and over-permissive default roles dominate real-world incidents.

The fix is architectural: enforce authorization at the data layer, not the controller layer. Every database query for user-owned resources should include the owner ID in the WHERE clause, and your ORM should make it hard to forget. The OWASP Top 10 project page has detailed prevention guidance for each category.

Cryptographic Failures Hide in Plain Sight

The bar for “encrypted in transit and at rest” is now table stakes. The interesting failures are subtler: storing passwords with fast hashes (use bcrypt, scrypt, or argon2id with appropriate cost parameters), encrypting sensitive fields with deterministic encryption that allows pattern analysis, or rolling your own crypto for “performance reasons.”

Use vetted libraries and KMS-backed key management. AWS KMS, Google Cloud KMS, and HashiCorp Vault each solve the key management problem better than anything you will build in-house.

Injection Has Evolved Beyond SQL

Parameterized queries killed most SQL injection a decade ago, but injection moved up the stack. NoSQL injection through unvalidated MongoDB filter objects, command injection through shell calls in worker queues, LDAP injection in enterprise auth, and template injection in server-rendered email templates are all alive and well.

The pattern is the same: never construct queries by concatenating user input. Use prepared statements, parameterized queries, or strict allowlists. Combine with the practices in our AI-powered cybersecurity guide for modern detection capabilities.

Photo by Pixabay on Unsplash

Insecure Design Cannot Be Patched Later

This category was added because too many “vulnerabilities” are not implementation bugs — they are design flaws. Password reset flows that leak account existence, business logic that allows negative quantities in checkout, rate limits that protect login but not signup.

Threat modeling at design time is the answer, and it is not as heavyweight as people fear. A 30-minute whiteboard session with the question “how would I abuse this?” catches more bugs than any scanner. Document the trust boundaries and review them in code review.

Software Supply Chain Is the New Frontier

Supply chain attacks like the xz-utils backdoor and various npm package takeovers have made dependency management a security concern, not just a maintenance one. Pin your dependencies, use lockfiles, audit critical paths, and consider tools like Socket.dev or GitHub’s dependency review.

The SLSA framework documentation defines maturity levels for build pipeline integrity. Most teams should target SLSA Level 2 (signed provenance) as a baseline.

Wrap Up

OWASP Top 10 risks remain at the top of the list because the fixes require organizational discipline, not new tooling. Authorization at the data layer, vetted crypto libraries, parameterized queries, threat modeling, and supply chain hygiene are the unglamorous practices that actually prevent breaches. Combine these with CI/CD pipeline setup that automates security checks and you have a defense-in-depth posture worth having.

Frequently Asked Questions

Are SAST tools worth running in CI?

Yes for catching obvious issues, but treat them as a floor, not a ceiling. They produce false positives and miss logic flaws. Pair them with manual code review and threat modeling.

Should small teams hire a security consultant?

A one-time architecture review and threat model from a competent consultant is one of the highest-ROI security investments a small team can make. Quarterly is overkill; annually is reasonable.

How often should we rotate secrets?

Automated rotation every 90 days for service credentials, immediately on any suspected compromise, and on personnel changes for any human-held secret. Use a secrets manager so rotation is mechanical.

Is OAuth more secure than JWTs?

They solve different problems. OAuth is an authorization framework; JWTs are a token format. Most JWT misuse comes from rolling your own token validation — use a library and verify signatures correctly.

How do I justify security work to product?

Frame in business terms: cost of a breach, customer trust, compliance gates blocking enterprise sales. Specific historical incidents in your industry are more persuasive than abstract risk.

The post 7 Critical OWASP Top 10 Risks Every Web Team Must Address appeared first on GTWebs.