Authentication in cloud-native web apps in 2026 is not about rolling your own login form. It is about picking the right pattern for your topology — single-page app, server-rendered, mobile, or API-first — and wiring it to an identity provider you trust.
Here are the patterns that hold up in production.
The four shapes of modern auth
- Authorization Code + PKCE (SPAs and mobile). The default for anything client-side. No client secret, PKCE binds the token to the client, refresh via rotating tokens.
- BFF (Backend-for-Frontend) with session cookies. The comeback pattern. Keep tokens on the server, give the browser a signed session cookie. Works beautifully with SSR frameworks.
- Client Credentials (service-to-service). For machine-to-machine, scoped to one audience per client. Never reuse across services.
- Device Code (CLIs and IoT). For inputs without a browser.
What to put on the identity provider
- Entra ID / Auth0 / Clerk / Keycloak — pick one and commit
- Configure per-environment tenants or at least per-environment apps
- Enforce MFA at the IdP, not the app
- Use short-lived access tokens and refresh token rotation
Common mistakes
- Storing access tokens in
localStorage(XSS steals them instantly) - Treating ID tokens as access tokens
- Rolling custom JWT verification instead of using the IdP SDK
- Skipping audience and issuer checks
- No token revocation story
The BFF pattern in one paragraph
Your frontend talks only to your backend via HttpOnly, Secure, SameSite=Lax cookies. Your backend holds the real tokens, talks to downstream APIs on behalf of the user, and handles refresh. Result: zero tokens in JavaScript, no localStorage exposure, and CSRF is manageable with the usual double-submit pattern.
Originally published on the Horizon Tech Blog.
Top comments (0)