Cómo agregar autenticación de dos factores a tu app

Para agregar autenticación de dos factores (2FA) a tu app, deja que los usuarios registren una app de autenticación (TOTP) o una passkey como segundo factor, pídelo al iniciar sesión después de la contraseña y exígelo en el servidor, para que una sesión sin segundo factor no pueda llegar a los datos protegidos. Hazlo obligatorio para los administradores, opcional o según el riesgo para los demás, y define la recuperación de la cuenta antes de lanzar: perder el teléfono no debería dejar a nadie afuera para siempre, y el camino de recuperación no debería permitir saltarse el segundo factor.

En esta guía comparamos los tipos de factor, recorremos el 2FA en Supabase Auth (el backend que usan casi todas las apps hechas con IA), mostramos cómo exigirlo desde la base de datos y vemos la recuperación y las pruebas.

¿Qué segundo factor conviene ofrecer?

La Multifactor Authentication Cheat Sheet de OWASP recomienda ofrecer TOTP como opción práctica por defecto y passkeys cuando se pueda, y trata el SMS como la opción más débil. El NIST clasifica los códigos por SMS como autenticador "restringido" por el duplicado de SIM y la intercepción. Si tu app maneja dinero o datos personales sensibles, no dejes el SMS como única opción.

¿Cómo funciona el 2FA en Supabase Auth?

Supabase lo llama MFA, y su guía de MFA documenta dos tipos de factor: app de autenticación (TOTP) y teléfono (SMS o WhatsApp).

• TOTP es gratis y viene activado por defecto en todos los proyectos de Supabase.
• El MFA por teléfono es un complemento pago. Al momento de escribir esto, Supabase lo cobra a 75 dólares al mes para el primer proyecto y 10 dólares al mes por cada proyecto adicional, facturado por las horas que está activo, más lo que cobre tu proveedor de SMS por mensaje. La propia documentación de Supabase advierte que el MFA por teléfono es vulnerable al duplicado de SIM.

La idea clave es el nivel de verificación (assurance level) del token del usuario. Después de iniciar sesión con contraseña (o enlace mágico, o red social), la sesión es aal1. Cuando el usuario además verifica un segundo factor, pasa a aal2. Tu frontend, tu servidor y tus políticas de base de datos pueden revisarlo.

Registro del factor

1. El usuario abre los ajustes de seguridad y elige "Configurar app de autenticación".
2. Tu app llama a supabase.auth.mfa.enroll({ factorType: 'totp' }), que devuelve un código QR y un secreto.
3. El usuario escanea el QR con su app de autenticación.
4. Tu app llama a challenge y luego a verify con el código de seis dígitos que escribe el usuario. Recién ahí el factor queda activo.

Inicio de sesión

1. El usuario entra con su contraseña como siempre.
2. Tu app llama a supabase.auth.mfa.getAuthenticatorAssuranceLevel(). Si el nivel actual es aal1 y el siguiente es aal2, el usuario tiene un factor y hay que pedirle el código.
3. Muestra la pantalla del código y luego challenge y verify. La sesión sube a aal2.

Mandar al usuario a la pantalla del código desde el frontend es solo la mitad visible. La otra mitad es exigirlo.

¿Cómo exijo el 2FA para que no se pueda saltar?

Si solo el frontend revisa el segundo factor, quien tenga la contraseña puede llamar a tu API o a la base de datos directamente con la sesión aal1. Exígelo donde viven los datos. Para tablas que deben pedir 2FA a todos los que lleguen a ellas, la documentación de Supabase recomienda una política restrictiva:

create policy "Require MFA"
on public.payouts
as restrictive
to authenticated
using ((select auth.jwt() ->> 'aal') = 'aal2');

Las políticas restrictivas se combinan con las normales, así que el usuario necesita cumplir la regla de pertenencia de siempre y además tener una sesión aal2. La guía de Supabase también muestra variantes que aplican solo a quienes registraron un factor, útiles cuando el 2FA es opcional. En tus funciones de servidor, lee el campo aal del token verificado y rechaza aal1 en las acciones sensibles.

¿A quién le exijo el 2FA?

• Administradores y personal: siempre. Sus cuentas llegan a los datos de todos. En cómo proteger el panel de administración vemos el resto de esa configuración.
• Usuarios normales: ofrécelo y recomiéndalo, sobre todo en cuentas con dinero, datos sensibles o permisos de admin de un equipo.
• Verificación extra en acciones sensibles. Aunque el 2FA no sea obligatorio, pide el segundo factor antes de cambiar el correo o la contraseña, desactivar el 2FA, exportar datos o agregar un método de cobro. OWASP menciona justo esos momentos.

¿Cómo recupera la cuenta quien pierde el teléfono?

Defínelo antes de lanzar, porque ahí es donde suelen romperse los sistemas de 2FA. La guía de MFA de Supabase no describe códigos de recuperación, así que el método lo tienes que decidir tú. Opciones comunes:

1. Permitir más de un factor (por ejemplo, la app de autenticación en dos dispositivos, o una passkey más TOTP) y sugerir un respaldo al configurarlo.
2. Códigos de recuperación generados al registrar el factor, mostrados una sola vez, guardados cifrados y de un solo uso. Esto lo construirías tú.
3. Un proceso de soporte en el que una persona verifica la identidad antes de quitar un factor, con un tiempo de espera y un correo a la dirección de la cuenta.

Elijas lo que elijas, quitar un factor debería exigir una sesión aal2 o un paso de recuperación verificado, y debería disparar un correo a la cuenta. El flujo para recuperar la contraseña tampoco debe quitar el 2FA en silencio: después de cambiar la contraseña, el segundo factor sigue ahí.

¿Cómo pruebo mi configuración de 2FA?

1. Registra un factor en una cuenta de prueba, cierra sesión y vuelve a entrar. Te debe pedir el código.
2. En la pantalla del código, sáltala abriendo una página protegida directamente. La página no debe cargar datos.
3. Con la sesión aal1 (copia una petición de la pestaña Network), llama a una tabla o función protegida. Debe rechazarse.
4. Escribe un código incorrecto varias veces. Debes chocar con un límite.
5. Quita el factor y confirma que llega un correo de aviso.
6. Haz tu proceso de recuperación completo con una cuenta de prueba.

El OWASP Top 10 pone las fallas de autenticación en el puesto siete; mira nuestro resumen del OWASP Top 10 para apps hechas con IA para los riesgos relacionados.

Respuestas rápidas

¿El 2FA por correo alcanza? Apenas. Si alguien controla el correo del usuario, recibe tanto el enlace de recuperación como el código.

¿El 2FA va a molestar a mis usuarios? Menos si es opcional para la mayoría, obligatorio en acciones sensibles y rápido en dispositivos de confianza. Las passkeys suelen ser más rápidas que escribir una contraseña.

¿Supabase admite passkeys como segundo factor? Su guía de MFA documenta por ahora TOTP y teléfono. Revisa la documentación vigente si las passkeys te importan.

¿Mi herramienta de IA puede agregar el 2FA? Puede generar las pantallas. Revisa que la exigencia esté en la base de datos o en el servidor, no solo en el frontend.

¿Quieres ayuda para configurarlo?

El chequeo de salud gratis muestra lo que tu app expone desde afuera. Si quieres que una persona agregue el 2FA con la exigencia y la recuperación bien hechas, eso entra en nuestra revisión de seguridad de Supabase o en los planes de mantenimiento, o puedes escribirnos.