¿Qué es la autenticación sin contraseña (passwordless)?

La autenticación sin contraseña es un modelo de login que verifica la identidad con una clave del dispositivo o biometría, no con un secreto memorizado. En el lenguaje de los factores: elimina el “algo que sabes” y autentica con “algo que tienes” y “algo que eres” — y en las variantes más fuertes no existe secreto compartido alguno: el servidor almacena una clave pública, la clave privada nunca sale de tu dispositivo, y no hay nada que phishear, rellenar ni filtrar en masa. Las contraseñas persisten no porque sean buenas sino porque están instaladas; el passwordless es la migración por fin en marcha a escala.

Puntos clave

La ceremonia de WebAuthn, desmitificada

La maquinaria detrás de cada prompt de passkey — dos ceremonias, ningún secreto en tránsito:

REGISTRO                                  LOGIN
1 el servidor envía un desafío aleatorio  1 el servidor envía un desafío nuevo
2 navigator.credentials.create()          2 navigator.credentials.get()
3 el dispositivo crea un par de claves;   3 desbloqueo local por biometría/PIN,
  biometría o PIN lo protege                el dispositivo FIRMA el desafío
4 clave pública → el servidor; la clave   4 el servidor verifica con la clave
  privada nunca sale del dispositivo        pública guardada → sesión emitida

La credencial queda vinculada al ORIGEN: un dominio imitador recibe
una firma que no verifica en ningún lado. Esa propiedad — no la
biometría — es lo que significa "resistente al phishing".

La rampa más suave que la mayoría de las apps lanza primero — los magic links (enlaces mágicos), donde la bandeja de entrada es el factor:

// JavaScript / Node.js — Back4app JS SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await Parse.Cloud.run('requestMagicLink', { email: '[email protected]' });

// 2 · The link opens the app with the token; exchange it for a session
const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', {
  token: tokenFromLink, // single-use, expires in 15 minutes
});
await Parse.User.become(sessionToken); // logged in — no password exists

// Flutter / Dart — Back4app Flutter SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
await ParseCloudFunction('requestMagicLink')
    .execute(parameters: {'email': '[email protected]'});

// 2 · The deep link opens the app with the token; exchange for a session
final result = await ParseCloudFunction('redeemMagicLink')
    .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min
// Adopt the returned session token — logged in, no password exists

// iOS / Swift — Back4app Swift SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
_ = try await Cloud.run(name: "requestMagicLink",
                        parameters: ["email": "[email protected]"])

// 2 · The universal link opens the app with the token; exchange for a session
let result = try await Cloud.run(name: "redeemMagicLink",
                                 parameters: ["token": tokenFromLink])
try await User.become(sessionToken: result["sessionToken"] ?? "")
// logged in — no password exists

// Android / Kotlin — Back4app Android SDK
// Magic link via Cloud Code: possession of the inbox is the factor
// 1 · Request: generates a single-use token, emails the link
ParseCloud.callFunction<Map<String, Any>>(
    "requestMagicLink", mapOf("email" to "[email protected]"))

// 2 · The deep link opens the app with the token; exchange for a session
val result = ParseCloud.callFunction<Map<String, Any>>(
    "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min
ParseUser.becomeInBackground(result["sessionToken"] as String)
// logged in — no password exists

Passkeys vs. magic links vs. OTP: los métodos, en ranking

Todo método passwordless hereda la seguridad de algo — la tabla dice de qué:

La línea que importa pasa entre las dos primeras filas y el resto: los códigos, los links y las aprobaciones pueden todos retransmitirse por un proxy de phishing en vivo; las firmas atadas al origen, no — la misma línea divisoria trazada en el ranking de métodos del artículo de MFA, porque es la misma línea.

¿Sincronizada o ligada al dispositivo? El trade-off real

Las passkeys se dividen en dos modelos de custodia, y la diferencia es política, no pedantería. Las passkeys sincronizadas viven en un gestor de credenciales y se replican, cifradas de extremo a extremo, entre los dispositivos del usuario — perder el teléfono es un no-evento, y por eso la adopción del consumidor por fin se movió; el intercambio de confianza es que la cuenta de sincronización se vuelve la joya de la corona, custodiada por sus propios flujos de recuperación. Las claves ligadas al dispositivo (llaves de seguridad de hardware, autenticadores con atestación corporativa) nunca salen del hardware — la elección de alta garantía para admins y accesos regulados, con “enrola una de repuesto” como todo el plan de recuperación. Las directrices actuales del NIST zanjaron la discusión para el mainstream: los autenticadores sincronizados son aceptables en los niveles de garantía estándar, con los ligados al dispositivo reservados para el nivel más alto.

El problema de la recuperación, otra vez

El passwordless afila la regla más vieja de la autenticación: la cuenta es tan fuerte como su camino de recuperación más débil. Un login por passkey con fallback de OTP por email es, para un atacante, un login por OTP de email con pasos extra. No existe “restablecer” para una clave ligada al dispositivo — por diseño — así que la disciplina se adelanta: enrola dos o más autenticadores en dispositivos separados desde la configuración, emite códigos de recuperación offline, trata los métodos de fallback como decisiones de seguridad y no como conveniencias de soporte, y convierte la eliminación de un autenticador en un evento con step-up, registrado y que dispara alertas. Los despliegues que se saltan esto lo reaprenden por la vía del help desk.

No es versus MFA — es una fusión

El encuadre “passwordless vs. MFA” de las páginas de comparación de proveedores es un falso binario. MFA significa múltiples categorías de factor; passwordless significa ningún secreto memorizado. Una passkey desbloqueada con la huella es ambas cosas: posesión del dispositivo más inherencia en el desbloqueo — multifactor en un solo gesto, con el elemento phisheable eliminado en lugar de complementado. La consecuencia práctica: las organizaciones no eligen entre los dos; migran de “contraseña + segundo factor” a “passkey”, que es un punto estrictamente más fuerte en la misma curva.

Casos de uso comunes

• Login de apps de consumo — passkeys como camino promovido; magic links como fallback de baja fricción.
• Comercio de visita recurrente — donde la fricción del login es ingreso medible, el login en un gesto se paga solo.
• Acceso de la fuerza laboral — autenticadores resistentes al phishing como política para admins y roles de alto privilegio.
• Productos passwordless-first — onboarding por link de email u OTP sin lanzar nunca un campo de contraseña.
• Momentos de step-up — una ceremonia de passkey como reautenticación antes de pagos, eliminaciones y exportaciones de claves.

¿Deberías adoptar el passwordless? Matriz de decisión

Limitaciones y trade-offs

• La cobertura no es universal. No todo sitio, navegador y stack corporativo soporta passkeys todavía; las contraseñas quedan como andamiaje de compatibilidad — por eso la coexistencia le gana a la migración en precipicio.
• El ecosistema custodia las claves. Las passkeys sincronizadas delegan la custodia a los gestores de credenciales de las plataformas — una dependencia de disponibilidad y confianza que heredas en vez de operar.
• La recuperación es el proyecto de verdad. La ceremonia más fuerte con un camino de reset débil es teatro; presupuesta la UX de enrolamiento y la política de fallback, no solo la integración de WebAuthn.
• El passwordless más débil sigue siendo más débil. Los magic links y el SMS quitan la contraseña sin agregar resistencia al phishing — un upgrade, no el destino.
• Los modelos de soporte cambian. Los tickets de “olvidé mi contraseña” se vuelven tickets de “perdí mi dispositivo”; los help desks necesitan procedimientos de verificación que no se conviertan en el nuevo agujero de ingeniería social.

Passwordless en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El passwordless aquí es un patrón que compones a partir de los primitivos de la plataforma, y las pestañas de código muestran el canónico: un flujo de magic link construido con dos funciones de Cloud Code — requestMagicLink genera un token de un solo uso y expiración corta, lo almacena en el usuario y envía el link por email; redeemMagicLink lo valida del lado del servidor y devuelve un token de sesión que el SDK adopta, de modo que el cliente nunca manipula credenciales. Más allá de los links, los adaptadores de auth personalizados de Back4app conectan proveedores de OTP y passkeys al mismo mecanismo de authData que impulsa el login social — un objeto de usuario, varios métodos de login, vinculables y desvinculables por usuario, que es la disciplina de recuperación (múltiples métodos enrolados) expresada como modelado de datos. Las sesiones siguen siendo revocables todo el tiempo: sea cual sea la ceremonia, la credencial que emite puede matarse en el momento en que algo se vea mal.