Cómo poner login y usuarios en tu app sin programar

Montas tu primera aplicación sin código y todo va bien. Las tablas, las pantallas, los formularios. Fluido.

Y entonces llegas a "y aquí cada usuario tiene que entrar con su cuenta y ver sus cosas".

Ahí se para todo el mundo. Porque el acceso de usuarios parece de otra categoría: contraseñas, seguridad, recuperar la clave, sesiones. Suena a la parte que sí necesita un programador.

Pues no. Es de las pocas cosas de este mundo que están completamente resueltas, y hay dos formas de hacerlo según lo que estés montando.

¿Cómo funciona el login en una app sin código?

Hay tres piezas y conviene distinguirlas porque la gente las mezcla.

Autenticación: comprobar que eres quien dices. La contraseña, el enlace mágico al correo, el "entrar con Google". Es la puerta.

Autorización: decidir qué puedes ver una vez dentro. Es lo que hace que el cliente A no vea lo del cliente B. Es el filtro.

Gestión de usuarios: dar de alta, invitar, quitar accesos, cambiar roles.

La autenticación viene hecha. Nadie construye eso a mano hoy en día, ni los programadores. La autorización es la que tienes que pensar tú, porque depende de tu negocio y ninguna herramienta la puede adivinar.

Y la mayoría de los líos de permisos vienen de creer que al activar el acceso ya están resueltas las tres cosas.

Ruta 1: que lo ponga la propia plataforma

Es la ruta buena para el noventa por ciento de los casos.

Herramientas como Softr traen los usuarios integrados. Le señalas cuál de tus tablas contiene la lista de personas, cuál es la columna del correo, y ya tienes pantalla de acceso, registro, recuperación de contraseña y sesión.

Con eso puesto, cada bloque de tu aplicación puede tener una condición del tipo "enseña solo las filas donde el cliente sea el usuario que ha entrado". Ahí está tu autorización, y es un desplegable, no código.

Los roles se hacen igual de simple: añades una columna "rol" en tu tabla de personas con valores como cliente, colaborador o administrador. Y en cada página pones quién puede verla según esa columna.

Lo desarrollo con un caso completo en cómo montar un portal privado para clientes, que es el ejemplo más típico de todos.

La pega de esta ruta: se paga por usuario con acceso. Con veinte clientes es una tontería. Con dos mil usuarios, la cuenta cambia bastante.

Ruta 2: la autenticación por debajo, con Supabase

Cuando lo anterior no encaja (porque son muchos usuarios, porque quieres control, o porque tu aplicación no vive dentro de una plataforma cerrada), la alternativa es poner la autenticación en la capa de datos.

Supabase

Eso significa que la regla "cada uno solo ve lo suyo" no vive en la pantalla, vive en la base de datos. Aunque alguien intente pedir los datos por otro camino, no los va a recibir. Es más seguro por diseño.

¿Esto es sin código? A medias, y hay que ser honesto. Las reglas se escriben en un lenguaje de base de datos. Ahora bien, es exactamente el tipo de cosa que una IA te escribe bien si le explicas la regla en español. Le dices "quiero que cada usuario solo pueda leer las filas de la tabla proyectos donde la columna propietario sea su identificador" y te da la regla lista para pegar.

Tengo el montaje completo en Supabase como base de datos de tu app con IA.

Cuál elegir, sin marear

Plataforma con usuarios integrados si: son usuarios que tú das de alta uno a uno (clientes, colaboradores, un equipo), la cantidad es manejable, y quieres tenerlo funcionando esta semana.

Autenticación en la capa de datos si: esperas cientos o miles de usuarios que se registran solos, manejas datos donde un fallo de permisos sería grave, o quieres que la aplicación pueda crecer sin que el precio dependa de cuánta gente entra.

Y si dudas, empieza por la primera. Migrar de una a otra es trabajo, sí, pero es menos trabajo que montar la compleja para un proyecto que nunca llegó a tener usuarios.

Los tres tipos de acceso y cuál poner

Correo y contraseña. Lo clásico. Funciona y a la gente le suena. Su problema es que la gente olvida contraseñas y tú acabas atendiendo recuperaciones.

Enlace mágico. Metes tu correo, te llega un enlace, pulsas y estás dentro. Sin contraseña. Para portales de clientes es mi favorito: no hay nada que olvidar. La pega es que depende de que los correos lleguen y no acaben en la carpeta de no deseados.

Entrar con Google. Un botón y dentro. Comodísimo, cero fricción. Solo sirve si tus usuarios usan cuentas de Google, que en empresas es casi siempre y en particulares también.

Yo pondría enlace mágico para portales privados y entrar con Google si tu aplicación es más abierta. Contraseñas solo si tus usuarios lo esperan.

Lo que se te va a atascar

Los correos que no llegan. Es el problema número uno de todo esto, sin discusión. Las invitaciones y los enlaces mágicos acaban en la carpeta de no deseados. Solución: configura un servicio de envío en condiciones desde el principio y avisa al usuario por otro canal de que le va a llegar.

Poner el filtro solo en el listado. Filtras la página de lista pero se te olvida la de detalle. Alguien con la dirección directa entra a algo que no es suyo. Filtra en las dos, siempre.

Confundir esconder con proteger. Que un botón no se vea no significa que la acción esté bloqueada. En la ruta de la plataforma esto suele estar bien resuelto, pero si montas cosas a medida, la regla de verdad tiene que estar en los datos, no en lo que se ve.

Los roles que crecen sin control. Empiezas con dos roles y a los tres meses tienes siete, con casos especiales, y no hay quien lo entienda. Cuando llegues a cuatro roles, párate y replantea: casi siempre son dos roles y un par de casos que se resuelven con un campo de la ficha.

Probar solo con tu cuenta. Tú eres administrador y lo ves todo, así que todo funciona. Créate una cuenta de prueba con perfil de usuario normal y entra con ella en una ventana aparte. Es la única forma de ver lo que ve tu cliente de verdad. Y hazlo cada vez que toques permisos.

Los datos de las personas. En cuanto tienes usuarios, tienes datos personales, y eso trae obligaciones: contarle a la gente qué guardas, poder borrarlo si lo piden, y no dejarlo tirado en cualquier sitio. Es aburrido y es tu responsabilidad desde el primer usuario.

Y ahora qué

Móntalo pronto, no al final. El error clásico es construir la aplicación entera pensando "el acceso lo pongo cuando esté todo", y luego resulta que la estructura de datos no aguanta los permisos que necesitas y hay que rehacer medio proyecto.

Ponlo cuando tengas dos pantallas. Con una tabla de personas, dos usuarios de prueba y un filtro ya sabes si tu estructura funciona.

Y luego pruébalo entrando como usuario normal, no como tú. Que es la parte que todo el mundo se salta y la que descubre los problemas.

El mapa completo de opciones para crear aplicaciones sin programar lo tengo aparte, con qué herramienta encaja en cada tipo de proyecto.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Si no tienes claro qué te conviene montar en tu caso, el test te da una ruta según lo que ya sabes hacer.

Hacer el test de IA