Autenticación moderna: OAuth 2.1, passkeys y el fin (relativo) de las contraseñas

Dos movimientos han cambiado de verdad cómo se diseña la autenticación en 2026. El primero es de estándares: OAuth 2.1 consolida en un único documento una década de parches de seguridad que hasta ahora vivían dispersos en RFCs y best current practices separadas. El segundo es de adopción real: las passkeys han dejado de ser una promesa de conferencia y ya están instaladas, según la FIDO Alliance, en miles de millones de cuentas activas. Ninguno de los dos sustituye por completo lo anterior de un día para otro, pero ambos deberían influir en cómo diseñas la autenticación de cualquier API o aplicación nueva.

OAuth 2.1: consolidación, no revolución

Lo primero que conviene entender de OAuth 2.1 es que no es un protocolo nuevo. Es, en palabras del propio grupo de trabajo de IETF, una consolidación: toma OAuth 2.0 (RFC 6749), PKCE (RFC 7636) y las recomendaciones de seguridad acumuladas en el OAuth 2.0 Security Best Current Practice y las funde en un único documento coherente. La idea es que un equipo que implemente “OAuth 2.1” a secas obtenga por defecto un resultado seguro, sin tener que conocer y aplicar manualmente media docena de RFCs adicionales para no cometer errores ya conocidos desde hace años.

Los cambios concretos que sí importan para quien construye un servidor de autorización o integra un flujo OAuth:

• Fuera el implicit grant y el resource owner password credentials grant. Ambos exponían tokens de forma insegura (el primero los devolvía directamente en el fragmento de la URL; el segundo pedía usuario y contraseña directamente a la aplicación cliente, entrenando a los usuarios a introducir sus credenciales fuera del proveedor de identidad). OAuth 2.1 los elimina de la especificación base.
• PKCE obligatorio para todo flujo de código de autorización, no solo para clientes públicos como se recomendaba en 2.0. Esto cierra el ataque de interceptación del código de autorización incluso en clientes confidenciales.
• Coincidencia exacta de redirect_uri. Se acabó el matching por prefijo o comodines, que era una de las vías más explotadas para robar códigos de autorización redirigiendo a un dominio controlado por el atacante.
• Los tokens no viajan en la query string. Deben ir en el cuerpo de la petición o en cabeceras, nunca en una URL que pueda acabar en un log de servidor o en el historial del navegador.
• Recomendación de sender-constrained tokens (mTLS o DPoP) para refresh tokens de clientes públicos, de modo que un token robado no sirva de nada sin la clave privada asociada al cliente que lo obtuvo.

Si tu backend ya usa una librería o proveedor de identidad mantenido activamente (Auth0, Clerk, Keycloak, o el propio oauth4webapi en Node), es muy probable que ya cumplas la mayoría de estos puntos sin cambiar nada: son las propias librerías las que han ido incorporando estas restricciones a medida que se consolidaban como buena práctica, años antes de que existiera un borrador formal de OAuth 2.1.

Passkeys y WebAuthn: cómo funciona de verdad por dentro

Una passkey no es “una contraseña más larga guardada en el móvil”. Es una aplicación práctica de criptografía de clave pública: en el registro, el dispositivo del usuario genera un par de claves, guarda la privada en un almacén seguro del propio dispositivo (el enclave seguro de un móvil, el TPM de un portátil, o una llave física tipo YubiKey) y envía solo la clave pública a tu servidor. Esa clave privada no sale nunca del dispositivo, ni siquiera en el proceso de autenticación.

El protocolo que estandariza esto es WebAuthn (ya en su versión 3, publicada como recomendación del W3C), que define dos ceremonias:

1. Registro (attestation). El servidor genera un reto (challenge) aleatorio. El autenticador del usuario crea un nuevo par de claves, firma el reto junto con metadatos del origen (dominio) y devuelve la clave pública más la firma. El servidor verifica la firma y guarda la clave pública asociada a esa cuenta.
2. Autenticación (assertion). El servidor genera un nuevo reto aleatorio. El autenticador firma ese reto con la clave privada que nunca ha salido del dispositivo. El servidor verifica la firma con la clave pública que ya tenía guardada. Si coincide, la autenticación es válida.

sequenceDiagram
participant U as Usuario (autenticador)
participant S as Servidor (relying party)
S->>U: Reto aleatorio (challenge)
U->>U: Firma el reto con la clave privada del dispositivo
U->>S: Firma + clave pública (solo en registro)
S->>S: Verifica la firma con la clave pública guardada
S->>U: Autenticación válida

Esto tiene dos consecuencias de seguridad directas que ninguna contraseña, por larga que sea, puede ofrecer: no hay ningún secreto compartido que un atacante pueda robar de una base de datos filtrada (la clave pública, por definición, no sirve para autenticarse sin la privada), y el reto aleatorio impide ataques de repetición, porque cada intento de login firma un desafío distinto. Además, WebAuthn ata la firma al origen (dominio) exacto que la solicitó, lo que hace que el phishing clásico —una web idéntica en un dominio distinto pidiendo credenciales— deje de funcionar: el navegador ni siquiera ofrece usar la passkey en un dominio que no es el registrado.

Para profundizar en la implementación práctica de WebAuthn como mecanismo de autenticación de aplicaciones, conviene revisar Passkeys y WebAuthn: guía definitiva, centrado específicamente en el flujo de integración.

Adopción real en 2026: mejor de lo que parecía hace dos años, lejos de ser universal

Los datos de la FIDO Alliance para 2026 muestran una curva de adopción que ya no es solo entusiasmo de early adopters: se estiman alrededor de cinco mil millones de passkeys activas a nivel global, con un 90% de reconocimiento de la palabra “passkey” entre usuarios encuestados y cerca de un 75% que ha activado al menos una en alguna cuenta. La cifra que más importa para un equipo de producto, sin embargo, es la de uso recurrente real: alrededor de un 49% de usuarios las emplea “siempre que puede” o “la mayoría de las veces” cuando la opción está disponible, y el rendimiento medido en tasa de éxito de login favorece claramente a las passkeys (en torno al 93%) frente a la contraseña tradicional (alrededor de 63%), sobre todo porque se eliminan los fallos de “contraseña olvidada” y los bloqueos por intentos fallidos.

La adopción, eso sí, es muy desigual por sector: fintech lidera con cifras que rondan el 60% de implementación, frente a un 18-28% en medios y SaaS. Esto tiene sentido: los sectores con mayor coste por fraude o cuenta comprometida han tenido el incentivo económico más claro para migrar primero.

Cómo migrar de forma gradual sin romper nada

Ningún equipo serio elimina las contraseñas de un día para otro, y no hace falta hacerlo. El camino que están siguiendo la mayoría de aplicaciones en 2026 es incremental:

1. Añade passkeys como método adicional, no como reemplazo. El usuario sigue teniendo su contraseña (o su proveedor OAuth externo) como alternativa mientras se familiariza con la nueva opción.
2. Ofrece registrar una passkey justo después de un login exitoso con el método antiguo, en el momento de mayor confianza de la sesión, en lugar de pedirlo en frío durante el registro inicial.
3. Usa WebAuthn también como segundo factor antes de plantearte sustituir la contraseña por completo: es una mejora de seguridad inmediata y de bajo riesgo, porque no cambia el flujo principal de login.
4. Mide la tasa de éxito real por método antes de tomar decisiones agresivas como ocultar la opción de contraseña. Los datos de tu propia base de usuarios importan más que cualquier estadística de adopción global.
5. Diseña la recuperación de cuenta desde el primer día: un correo de verificación, códigos de recuperación de un solo uso, o un segundo dispositivo ya vinculado son la diferencia entre una passkey perdida siendo un inconveniente o un usuario bloqueado para siempre.

La combinación de OAuth 2.1 para delegar autorización entre servicios y passkeys para la autenticación directa del usuario cubre, en 2026, la inmensa mayoría de los escenarios de identidad que necesita una aplicación moderna. Lo que ya no tiene sentido en un sistema nuevo es diseñar un flujo de autenticación basado únicamente en contraseña sin al menos ofrecer una alternativa sin contraseña: el coste de implementarlo ha bajado mucho más rápido que el coste de seguir sufriendo brechas de credenciales reutilizadas.