Magic Link & Passwordless

Los passkeys (WebAuthn/FIDO2) son la autenticación sin contrasena más segura disponible: usan criptografia de clave publica donde la clave privada nunca sale del dispositivo. Magic links y OTP por email o SMS son alternativas validas para bajo riesgo, pero dependen de la seguridad del buzon o del canal de mensajeria. En apps con datos sensibles, pagos o acceso empresarial, el passkey debe ser el botón prominente y los demas métodos, un enlace secundario, no opciones del mismo peso. FIDO reporta 53% de adopción de passkeys en al menos una cuenta y mejoras medibles de Google (4x en tasa de exito de login) y Amazon (6x más rápido).

El fallo más frecuente del magic link ocurre cuando el usuario pide el enlace en su laptop pero abre el correo en el telefono: la sesión queda autenticada en el lugar equivocado. Los clientes de correo embebidos (apps de Gmail u Outlook) abren el link en un navegador interno que no comparte cookies con el navegador principal, rompiendo el flujo; cerrar el loop con PKCE evita MITM pero rompe el multi-dispositivo. El problema es estructural y no tiene solución elegante solo con el link. La solución correcta es incluir siempre un código de 6 digitos debajo del enlace, para que el usuario complete el login sin cambiar de dispositivo.

Dividir el código en seis cajas de un caracter es popular pero tecnicamente deficiente: los lectores de pantalla no navegan entre ellas de forma coherente, no se puede pegar el código completo de un gesto y el autofill nativo falla. Un campo único con inputmode="numeric", autocomplete="one-time-code" y un aria-label descriptivo cumple WCAG 1.3.5 (Identify Input Purpose, AA) y habilita el autofill de SMS en iOS y Android. Usa type="text" y no type="number": el numérico agrega flechas de incremento y rompe el formato.

Los passkeys son resistentes al phishing porque el par de claves esta ligado criptograficamente al dominio del servicio: ni el usuario ni el atacante pueden usar la credencial en un sitio falso. El SMS OTP, en cambio, se intercepta vía SIM swap, ataques SS7 o ingenieria social donde se convence al usuario de dictar el código; por eso OWASP clasifica el SMS como autenticador "restringido". No presentes ambos métodos con el mismo peso visual y el mismo nivel de confianza: comunica la ventaja del passkey con un badge claro y evita la falsa equivalencia. El 77% de las brechas por hacking involucran credenciales robadas (Verizon).

Cuando el usuario pierde acceso a su passkey o deja de recibir emails/SMS, la recuperación es el momento más critico del flujo passwordless: una mala recuperación obliga a soporte humano, genera abandono o abre una puerta trasera insegura. La estrategia debe definirse antes de lanzar, no después. Genera y muestra códigos de recuperación de un solo uso en el momento del registro del passkey, igual que los gestores de contrasenas y las apps 2FA, y nunca dejes el fallback de SMS/email como única vía. Tu cuenta es tan segura como su método de autenticación más débil.

Tras pedir un magic link o un OTP, el usuario queda esperando sin saber que buscar en su bandeja. Un mensaje vago como "Revisa tu correo" genera incertidumbre; el copy efectivo específica el canal exacto (email o telefono), los últimos digitos enmascarados del destino, que acción tomar y cuanto tiempo tiene. Anade un botón de reenvio con cuenta regresiva visible para que el usuario no quede atrapado si el mensaje no llega, y un atajo para usar el código en lugar del link. El contexto de entrega y la urgencia temporal son los dos factores que más reducen la fricción en este paso.

El campo de OTP necesita un proposito programaticamente determinable: una label visible "Código", un aria-label descriptivo y los atributos inputmode="numeric" y autocomplete="one-time-code". Esto cumple WCAG 2.2 SC 1.3.5 (Identify Input Purpose, AA), que exige que el proposito de los campos que recogen información del usuario pueda determinarse por software, y permite el autofill nativo de SMS en dispositivos compatibles. Sin esto, el lector de pantalla solo anuncia "campo de texto" y el usuario no sabe que escribir. El teclado numérico en móvil reduce errores y acelera la captura.

Un sistema passwordless que depende de un único canal (solo email, solo SMS, solo passkey) atrapa al usuario si ese canal falla: los emails llegan tarde o van a spam, el telefono se queda sin batería, el passkey puede no estar sincronizado. El principio de "no atrapar" exige que toda pantalla de autenticación muestre al menos una vía alternativa visible, no enterrada en un enlace de soporte, y preferentemente de un canal diferente al primario. NN/g recomienda ofrecer passwordless por defecto pero permitir al usuario adjuntar una contrasena después si lo prefiere. Los fallbacks deben existir, monitorearse y nunca ser la vía por defecto.