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

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

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? (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 HN retoma el debate clásico y llega a una convergencia 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 total 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 de localStorage para tokens sensibles (XSS = compromiso total, ya no hay debate). Dos: la madurez de los passkeys: la adopción masiva supera ahora el umbral crítico en los principales ecosistemas (Google, Apple, Microsoft los han desplegado todos), aunque ninguno ha publicado cifras detalladas recientes. Tres: los IdP 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 el passkey como 2FA «obligatorio» demasiado pronto: pérdida de cuenta si el usuario solo tiene un dispositivo.
• Falla de moda: las extensiones de navegador que leen la memoria de una SPA: otro argumento para no poner nada en localStorage.

Entonces, ¿qué?

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: los passkeys están listos; activarlos como opción ahora y exigirlos hacia 2027 en entornos empresariales. A vigilar: la estandarización de los passkeys entre plataformas (el verdadero freno en B2B).