Cómo se hace: INICIO DE SESIÓN
¡Buenas! En esta serie comparto experiencia del día a día sobre cosas sencillas y poco valoradas con las que tropiezan responsables de producto y propietarios.
Unos buscan la lógica correcta. Otros pelean con la captación, la retención y esa supuesta «UX perfecta».
Hoy os dejo la lógica del inicio de sesión para una web o una aplicación móvil. Gratis.
¿Por qué Google?
Hay que dejar entrar al usuario y saber con qué cuenta estamos trabajando. Parece fácil. Pero os garantizo que hay escenarios en los que ni habéis pensado.
Una de las opciones más sencillas es entrar con Google.
Ventajas:
Inconvenientes: los estafadores no desaparecen y no todo el mundo quiere entrar con Google. Investiga a las personas para las que construyes el producto.
¿Qué forma de acceso elegir?
¿Fiarnos del código del navegador y ya? No, gracias. El servidor tiene que verificar el token de ID: firma, emisor, destinatario correspondiente a tu aplicación y caducidad.
¿Gestionar el acceso y la sesión en el servidor? Sí. Especialmente en CRM y aplicaciones con datos sensibles. Tener un servidor no protege nada por arte de magia: hay que implementar las comprobaciones.
¿Google One Tap? Cómodo si buscas un recorrido rápido. Pero una ventana inesperada puede activar el «factor odio». No asustes a la gente con tu propia UX.
Datos: empieza por lo mínimo
Al configurar los scopes, entiende para qué sirve cada permiso. No recopiles información «porque se puede». Te están confiando su privacidad.
1. Pide solo los datos básicos del perfil que necesites.
2. Solicita edad, género u otros detalles únicamente si hay una necesidad real. Un inicio de sesión normal no te los entrega automáticamente.
3. Pide nuevos permisos cuando puedas explicar al usuario para qué le sirven.
La dichosa foto de perfil
¿Para qué la quieres? Para que el usuario reconozca su cuenta y sepa que está donde esperaba.
PODÉIS COPIAR ESTO: si tu producto necesita una copia propia, recoge el avatar disponible al registrarse y guárdalo en tu almacenamiento. En el siguiente acceso comprueba si ha cambiado. Si cambia, actualízalo. Si no hay foto, muestra una alternativa.
Incluye también esa copia en las reglas de conservación y borrado de datos.
Base de datos, privacidad y tablas
Explica en la política de privacidad lo que haces de verdad. ¿Publicidad? Explica el seguimiento y obtén el consentimiento que corresponda. ¿Almacenamiento? Prevé control de acceso y cifrado. El texto de la política no protege la base de datos.
Y no lo metas todo en el mismo saco.
Mantén separados los datos básicos del perfil. Las claves secretas de servicio se quedan en el servidor, no en el navegador. Comprueba los permisos en cada operación.
Siguiente nivel: lo que es fácil pasar por alto
1. Vincular cuentas. Email con contraseña y Google deben llevar a una misma cuenta cuando se trata realmente de la misma persona. Pero un email coincidente no basta para fusionar cuentas sin más. Confirma el control de ambos métodos; vincula la identidad de Google mediante el identificador estable `sub`, no mediante una dirección que puede cambiar. Actualiza por separado la fecha del último acceso.
2. Tokens y sesiones. El token de ID acredita la identidad; el access token permite acceder a una API. No los confundas. Una sesión en el servidor, por ejemplo en Redis, o una sesión bien configurada con JWT: depende de la arquitectura. La cookie tiene que estar protegida. Las siglas JWT no hacen magia.
3. Borrar datos. Diseña un proceso real de borrado o anonimización adecuada, incluyendo la copia del avatar y los registros relacionados. «Le pusimos sal y calculamos un hash» no significa «ya no se puede identificar a nadie». Si otros datos permiten reconstruir la identidad, es seudonimización, no anonimización. Revisa las condiciones de conservación de ciertos datos para tu caso concreto.
Y ya está. Un botón de acceso y toda esta lógica detrás. No puedes separar el inicio de sesión de los datos que toca.
