Modern authentication: passkeys, OIDC, sessions - the real short list

In plain terms

In 2026, the "right" way to authenticate a web application depends on two questions: (1) are you a B2C consumer app, or a B2B SaaS? (2) are you ready to operate your own IdP, or do you rely on a provider? The patterns of the mid-2020s (JWT stateless + refresh in localStorage) are outdated - for good reasons.

The case

The HN thread picks up the classic discussion and arrives at an interesting convergence: for most apps, the pragmatic 2026 stack is:

1. Server-side encrypted session in HttpOnly + SameSite=Lax cookie for authentication state. No more JWT stored client-side.
2. OIDC (Google/Apple/GitHub) for passwordless onboarding.
3. Passkeys (WebAuthn) for the second step or complete password replacement. It's finally adopted everywhere (iOS 17+, Android 13+, all browsers).
4. Short server-side session rotation (~1h) + long refresh (~14d) via separate cookie.
5. No JWT client-side, unless you have real stateless multi-tenant to do.

What has changed, structurally, is three things. One: the end of localStorage for sensitive tokens (XSS = total compromise, there's no more debate). Two: the maturity of passkeys - public adoption now exceeds the critical threshold in major ecosystems (Google, Apple, Microsoft have all deployed), even if none has published a recent detailed figure. Three: hosted IdPs (Clerk, WorkOS, Auth0) now offer turnkey SSO/SCIM/passkeys coverage that no team of fewer than 5 people has any interest in reimplementing.

Under the hood

• Cookie session: Secure; HttpOnly; SameSite=Lax; __Host- prefix. Rotation on each privilege escalation.
• CSRF: SameSite=Lax covers 95% of cases; adding a CSRF token on sensitive mutations is the belt.
• PKCE mandatory on all public OAuth flows (SPA, mobile).
• Common pitfall: putting the passkey in "mandatory" 2FA too early - account loss if the user has only one device.
• Trending flaw: browser extensions that read the memory of a SPA - additional argument for putting nothing in localStorage.

So what

Three takeaways. One: if you're starting in 2026, take a provider (Clerk, WorkOS, Stack Auth) unless you have a specific regulatory reason. The engineering time saved goes to the product. Two: if you have a legacy JWT-in-localStorage stack, plan the migration to session cookie - it's a priority security task, not cosmetic. Three: passkeys are ready; to be activated as an option now, and to be enforced by 2027 in enterprise. To watch: the standardization of cross-platform passkeys (the real B2B hurdle).