1 
2Las contraseñas son una de esas cosas que hemos normalizado simplemente porque hemos vivido con ellas durante años. Los usuarios los olvidan, los reutilizan, los escriben donde no deberían. Los equipos deben gestionar restablecimientos, políticas, hashes, filtraciones, phishing y soporte.
3 
4El passkey no hace que la autenticación sea perfecta, pero elimina un gran problema: el servidor ya no tiene que guardar un secreto compartido con el usuario.
5 
6## ¿Qué pasa realmente?
7 
8Un passkey es una credencial basada en WebAuthn. Cuando el usuario lo crea, el dispositivo genera un par de claves:
9 
10- una clave privada, que permanece en el dispositivo o en el administrador de contraseñas;
11- una clave pública, que el servidor puede guardar.
12 
13Al iniciar sesión, el servidor no pregunta "dime la contraseña". Envía un desafío aleatorio. El dispositivo lo firma con la clave privada. El servidor verifica la firma con la clave pública.
14 
15Esa es la parte buena: si roban la base de datos, no hay contraseñas en su interior que puedan descifrarse. Y si un usuario termina en un dominio falso, el passkey no es válido para ese dominio. No se trata sólo de comodidad, sino de una protección concreta contra el phishing.
16 
17## El navegador actúa como puente
18 
19En el navegador los dos principales API son:
20 
21- `navigator.credentials.create()` para crear un passkey;
22- `navigator.credentials.get()` para usarlo durante el inicio de sesión.
23 
24Pero la lógica importante está en el servidor. El servidor debe generar el desafío, guardarlo temporalmente, verificar la respuesta, verificar la fuente y Relying Party ID, luego crear la sesión.
25 
26La parte del cliente debería ser casi aburrida:
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42Si te encuentras implementando el cifrado WebAuthn manualmente, detente. Utilice una biblioteca sólida del lado del servidor. Los errores aquí no son "errores lindos", son agujeros de autenticación.
43 
44## Qué guardar en la base de datos
45 
46No hay necesidad de salvar a la mitad del mundo. Generalmente es suficiente:
47 
48- ID de la credencial;
49- clave pública;
50- usuario conectado;
51- cualquier contador de verificación o metadatos;
52- transportes, si son útiles para la UX;
53- nombre elegido por el usuario;
54- fecha de creación y último uso.
55 
56Una tabla mínima podría verse así:
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70Luego agregaría registros de auditoría y notificaciones: si alguien crea un nuevo passkey en mi cuenta, quiero saberlo.
71 
72## UX importa más que la demostración
73 
74La demostración de un passkey siempre es hermosa: haces clic en Face ID y estás dentro. El producto real es más complicado.
75 
76Alguien cambia su teléfono. Alguien utiliza una computadora de la empresa bloqueada. Algunas personas no entienden por qué el navegador sugiere un passkey. Alguien pierde el acceso a su dispositivo.
77 
78Por eso no empezaría con "a partir de hoy no más contraseñas para todos". Yo empezaría así:
79 
801. passkey opcional para usuarios internos;
812. sugerencia de crear uno después de iniciar sesión correctamente;
823. página de cuenta para cambiar el nombre y eliminar passkey;
834. claro respaldo;
845. Implementación gradual en el inicio de sesión principal.
85 
86El texto de la interfaz debe ser sencillo. "Usar la pantalla de bloqueo de su dispositivo" es mejor que "autenticarse con una credencial de residente FIDO2".
87 
88## Errores que evitaría
89 
90No generar desafíos al cliente. El desafío se crea en el servidor y debe verificarse solo una vez.
91 
92No confíe sólo en la identificación de la credencial. Debe verificar la firma, la impugnación, el origen y Relying Party ID.
93 
94No elimine las reservas antes de tener un buen flujo de recuperación. Sin contraseña no tiene por qué convertirse en "si pierdes tu teléfono, quedarás fuera para siempre".
95 
96No trate el passkey como un botón puramente frontal. Ocultar un botón no es seguridad: la verdadera verificación es del lado del servidor.
97 
98## ¿Passkey-primero o passkey-amigable?
99 
100Para un producto nuevo, puede pensar en passkey-primero. Para una aplicación existente, prefiero passkey: agregue passkey como método recomendado, mida el éxito y los problemas, luego reduzca con calma el peso de la contraseña.
101 
102La migración ideal no se siente. El usuario descubre que iniciar sesión es más fácil, no que la empresa haya cambiado su protocolo de autenticación.
103 
104## Conclusión
105 
106Los passkey son interesantes porque mejoran la seguridad y la UX al mismo tiempo, lo cual es poco común. No son una varita mágica: la recuperación, la compatibilidad, el soporte y la implementación aún deben diseñarse bien.
107 
108Pero el cambio básico es fuerte. Deja de pedir a los usuarios que inventen y protejan secretos. Dejas que el dispositivo firme una prueba criptográfica vinculada a tu dominio. Menos memoria humana, menos phishing, menos restablecimientos de contraseñas. Yo diría que vale la pena tomarlos en serio.
109 
110## Fuentes
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116