Login y autenticación en una app: opciones y decisiones

El login en una app parece simple: un usuario y una contraseña. En la práctica incluye registro, recuperación de cuenta, sesiones, cierre de sesión en otros dispositivos y protección contra abusos. Y casi todas las demás funciones dependen de él. Esta página explica las opciones de autenticación, qué decisiones de diseño pesan y qué preguntar antes de incluirlo.

Autenticación y autorización

Son dos cosas distintas. La autenticación responde «¿quién sos?». La autorización responde «¿qué podés hacer?». Esta página trata la primera; la segunda se desarrolla en roles y permisos.

Las formas de ingresar

Email y contraseña

La opción más conocida. Da control total sobre las cuentas, pero implica guardar contraseñas de forma segura (nunca en texto plano, sino con un algoritmo de hash pensado para eso), pedir una verificación del email y ofrecer recuperación. Los usuarios reutilizan contraseñas y las olvidan, por lo que el flujo de recuperación pesa más que el de registro.

Login social

Ingresar con una cuenta de Google, Apple u otro proveedor reduce la fricción: no hay contraseña que recordar. A cambio, dependés de un tercero y de sus condiciones. Las tiendas pueden tener reglas sobre ofrecer ciertas opciones cuando se usa login social; verificá los requisitos vigentes de cada tienda antes de definir cuáles incluir.

Código por email o por mensaje

El usuario ingresa su email o teléfono y recibe un código o un link de un solo uso. Evita contraseñas, pero depende de que el mensaje llegue; en el caso de SMS, suma costo por envío y los problemas de entrega propios de ese canal.

Segundo factor

Un paso extra, por ejemplo un código generado en una app autenticadora. Recomendable para cuentas de administración o con datos sensibles, y opcional para el resto.

Cuál conviene según el proyecto

Situación	Camino habitual
Panel interno de un negocio con pocos empleados	Email y contraseña, con segundo factor para administradores
App para clientes que reservan ocasionalmente	Login social o código por email, para reducir fricción
Datos sensibles (salud, finanzas, documentos)	Contraseña robusta, segundo factor y registro de accesos
Uso sin cuenta posible	Reserva como invitado, con cuenta opcional después

Una pregunta previa: ¿realmente necesitás que el usuario tenga cuenta? Un link de reserva como el de Mateturnos funciona sin registro para el cliente final, mientras que el negocio sí ingresa con su cuenta. Cada barrera de entrada innecesaria reduce el uso.

Recuperación de cuenta

Es la parte más atacada y la más subestimada. Un flujo típico envía un link temporal al email registrado. Decisiones a tomar: cuánto dura el link, qué ocurre si se pide varias veces y qué se hace cuando el usuario ya no tiene acceso a ese email. Esa última situación requiere un proceso humano que hay que definir con anticipación.

Sesiones

Después del ingreso, la app mantiene una sesión mediante un token. Hay que decidir cuánto dura, si se renueva sola y si el usuario puede cerrar sesiones abiertas en otros dispositivos. En el celular, la comodidad de no reingresar cada vez choca con el riesgo de un teléfono perdido: una opción intermedia es pedir desbloqueo biométrico del propio dispositivo para acciones delicadas.

Seguridad básica que no debería faltar

• Comunicación cifrada (HTTPS) en todo momento.
• Contraseñas almacenadas con hash, nunca visibles ni siquiera para el equipo técnico.
• Límite de intentos fallidos para frenar adivinación automática.
• Mensajes de error que no revelen si un email existe o no.
• Registro de ingresos para cuentas administrativas.

Hay un conjunto más amplio de medidas en seguridad de datos. Además, los datos de las cuentas son datos personales, por lo que corresponde considerar la Ley 25.326.

Impacto en alcance y costo

Un login básico es de las partes más acotadas de un proyecto, pero cada extra suma: login social requiere configurar cada proveedor, el código por mensaje depende de un servicio de envío, el segundo factor agrega pantallas y casos de soporte. Una alternativa es apoyarse en un servicio de identidad de terceros en lugar de construir todo; ahorra trabajo, pero agrega dependencia y, según el volumen, costos recurrentes. Esa decisión se relaciona con la arquitectura general, que explicamos en qué es el backend.

Riesgos

• Construir un sistema propio sin necesidad, con huecos de seguridad.
• Dependencia de un proveedor que cambia sus condiciones.
• Soporte: gran parte de las consultas a una app son «no puedo entrar».

Qué preguntar antes de incluirlo

1. ¿Quiénes ingresan y qué ven al hacerlo?
2. ¿Puede usarse sin cuenta en alguna parte?
3. ¿Cómo se recupera una cuenta cuando se pierde el email?
4. ¿Qué datos sensibles hay y se justifica un segundo factor?
5. ¿Quién atiende los problemas de acceso?

Para definir el esquema de acceso de tu proyecto, contanos el caso en el formulario de contacto. Desde Rosario lo analizamos junto con el resto del alcance.