La autenticación moderna: passkeys, OIDC, sesiones - la verdadera lista corta

Un hilo popular en HN reabre la pregunta: ¿cómo debemos autenticar una aplicación en 2026? La respuesta ya no es «JWT + refresh token». Panorama general.

En términos sencillos

En 2026, la « buena » forma de autenticar una aplicación web depende de dos preguntas: (1) ¿eres una app B2C para el público general o un SaaS B2B? y (2) ¿estás dispuesto a operar tu propio IdP o delegas en un proveedor? Los patrones de mediados de los 2020 (JWT sin estado + refresh en localStorage) están obsoletos, y por buenas razones.

El tema

El hilo de Hacker News retoma el debate clásico y llega a una conclusión interesante: para la mayoría de las aplicaciones, la pila pragmática de 2026 es:

1. Sesión en servidor cifrada en cookie HttpOnly + SameSite=Lax para el estado de autenticación. Se acabó el JWT almacenado en el cliente.
2. OIDC (Google/Apple/GitHub) para el registro sin contraseña.
3. Passkeys (WebAuthn) para el segundo paso o como reemplazo completo de la contraseña. Por fin está adoptado en todas partes (iOS 17+, Android 13+, todos los navegadores).
4. Rotación corta de la sesión en servidor (~1h) + refresh largo (~14 días) mediante cookie separada.
5. Ningún JWT en el cliente, salvo que tengas que hacer autenticación stateless multi-tenant real.

Lo que ha cambiado estructuralmente son tres cosas. Uno: el fin del uso de localStorage para tokens sensibles (XSS = compromiso total, ya no hay debate). Dos: la madurez de las passkeys: la adopción masiva supera ahora el umbral crítico en los principales ecosistemas (Google, Apple, Microsoft las han desplegado todas), aunque ninguno ha publicado cifras detalladas recientes. Tres: los proveedores de identidad alojados (Clerk, WorkOS, Auth0) ofrecen ahora una cobertura SSO/SCIM/passkeys lista para usar que ningún equipo de menos de 5 personas debería reimplementar.

Bajo el capó

• Cookie de sesión: Secure; HttpOnly; SameSite=Lax; prefijo __Host-. Rotación en cada escalada de privilegios.
• CSRF: SameSite=Lax cubre el 95% de los casos; añadir un token CSRF en las mutaciones sensibles sigue siendo el cinturón de seguridad.
• PKCE obligatorio en todos los flujos OAuth públicos (SPA, móvil).
• Trampa frecuente: activar la passkey como 2FA « obligatoria » demasiado pronto: pérdida de cuenta si el usuario solo tiene un dispositivo.
• Vulnerabilidad de moda: las extensiones de navegador que leen la memoria de una SPA: otro argumento para no almacenar nada en localStorage.

¿Y entonces?

Tres conclusiones. Uno: si empiezas en 2026, usa un proveedor (Clerk, WorkOS, Stack Auth) salvo que haya una razón regulatoria específica. El tiempo de ingeniería ahorrado va al producto. Dos: si tienes una pila heredada con JWT en localStorage, planifica la migración a cookie de sesión: es un trabajo de seguridad prioritario, no cosmético. Tres: las passkeys están listas; activarlas como opción ahora y hacerlas obligatorias en entornos empresariales para 2027. A vigilar: la estandarización de las passkeys entre plataformas (el verdadero freno para B2B).