¿Necesitas construir tu propia autenticación para aplicaciones?

Antecedentes#

He visto a muchos desarrolladores haciendo preguntas como "¿Debería construir mi propia autenticación para mi aplicación?". Aunque la respuesta no puede ser un simple "Sí" o "No", me gustaría escribir un artículo para desglosar la implementación y demostrar los pros y contras para ayudarte a decidir.

TL;DR Es necesario encontrar una solución existente que se ajuste a tus necesidades, a menos que realmente quieras un control total o todavía estés aprendiendo desarrollo de software.

Introducción#

Como desarrollador, he construido muchas aplicaciones durante mi carrera. Independientemente del lenguaje de programación, siempre hay una base común que necesito construir: la autenticación de usuario.

Era una parte insignificante ya que todo era sencillo hace 20 años:

• Implementar un sistema de registro e inicio de sesión con nombre de usuario y contraseña.
• Crear un mecanismo para mantener la sesión de un usuario.
• ¿Sobre seguridad? MD5 es la respuesta.

Eso es todo. Luego, podía concentrarme en "el verdadero negocio". ¿No has oído hablar de MD5? Te perdiste los "buenos tiempos" del desarrollo de software. Hoy en día, los desarrolladores se enfrentan a más desafíos al construir el inicio de sesión/registro.

Puede sonar alarmista, pero déjame explicarlo con un ejemplo.

Ejemplo: Una librería online#

Imaginemos que estás tratando de construir una librería online con un servicio de API y una aplicación frontend web.

Primero, el alcance de "autenticación" debe ser definido. La autenticación puede explicarse como autenticación y autorización, y tienen definiciones y casos de uso totalmente diferentes:

Escribí un artículo CIAM 101: Autenticación, Identidad, SSO para discutir estos conceptos en detalle.

Elegir métodos de autenticación#

Comencemos con la "autenticación", que es el inicio de sesión del usuario en nuestro ejemplo. Aparte del método de nombre de usuario y contraseña, aquí hay algunos métodos populares que las personas están adoptando para una mejor conversión de usuarios y seguridad:

• Sin contraseña, es decir, código de verificación dinámico (por correo electrónico o sms)
• Inicio de sesión social (Google, Facebook, etc.)

La elección del método depende de la decisión de negocio, mientras que podemos echar un vistazo al esfuerzo técnico:

• Para el método sin contraseña, necesitas encontrar un proveedor para enviar códigos de verificación por correo electrónico o sms; luego integrarlo con tu servicio de API (pueden ser necesarias nuevas API).
• Para el inicio de sesión social, debes cumplir con las pautas de integración del proveedor de identidad social que desees utilizar. Además, debes crear un mapeo entre los ID de usuario de tu librería y el proveedor de identidad.
  • Por ejemplo, cuando un usuario inicia sesión con una cuenta de Gmail [email protected], puedes vincular este correo electrónico con el usuario foo en la librería. Este proceso te ayuda a construir un sistema de identidad unificado y permite al usuario modificar o desvincular su identidad social en el futuro.

Diseñar e implementar la experiencia de inicio de sesión#

Después de decidir los métodos de autenticación, una experiencia de inicio de sesión elegante y fluida para tus usuarios finales es el siguiente objetivo. La conversión aquí es fundamental pero crucial para el negocio, ya que es una manera natural de dejar los datos del cliente persistidos.

Cuando trabajaba para Airbnb, había todo un equipo dedicado a optimizar la experiencia de inicio de sesión para múltiples plataformas. Realizaron numerosas pruebas A/B para determinar qué combinación tenía la tasa de conversión más alta.

No es práctico hacerlo cuando un negocio está empezando. Pero aún así necesitamos esforzarnos por hacer cada pieza correctamente. ¿En qué plataformas te gustaría ejecutar la librería? Puedes empezar con móvil, web, o ambos. El diseño exacto dependerá de los métodos de autenticación que elijas:

• Nombre de usuario y contraseña: El más fácil, sólo necesita algunas cajas de entrada y botones.
• Sin contraseña: Ingresar teléfono / correo electrónico, luego enviar y verificar un código dinámico.
• Inicio de sesión social: Leer la documentación del proveedor de identidad social elegido, seguir la guía visual, manejar la lógica de redirección, y finalmente vincular la identidad social con la identidad de la librería.

Más cosas a considerar para mejorar:

• ¿Necesitas combinar el proceso de inicio de sesión y registro para un método específico?
• ¿Necesitas un flujo de "olvidé mi contraseña" para permitir a los clientes resetear sus contraseñas independientemente?

Si optas por el desarrollo nativo, la carga de trabajo casi se duplicará para una plataforma adicional.

Seguridad e intercambio de tokens#

La seguridad puede ser un iceberg oculto. Será genial si estás familiarizado con OpenID Connect o OAuth 2.0, ya que son ampliamente utilizados y probados en batalla. OpenID Connect es relativamente nuevo pero está diseñado para "autenticación de usuario", que es perfecto para una librería online.

Sin profundizar en los detalles de los estándares, aún hay algunas cosas a considerar:

• ¿Qué método de cifrado debe ser utilizado para las contraseñas?
• ¿Cuál es el proceso para la autenticación y autorización estándar?
• ¿Cómo funciona el intercambio de tokens (Token de Acceso, Token de Actualización, ID de Token, etc.)?
• ¿Cómo pueden usarse las claves de firma en los tokens y cómo puede validarse la firma para proteger los recursos?
• ¿Cómo se pueden prevenir los ataques al cliente y al servidor?

Finalmente, puedes lograr una buena experiencia de inicio de sesión y ofrecerla a tus clientes.

Modelo de autorización#

Como librería, necesitas separar los recursos para los clientes y los vendedores. Por ejemplo, los clientes pueden navegar por todos los libros, mientras que los vendedores pueden gestionar sus libros en venta. Está bien comenzar con simples comprobaciones if-else; sin embargo, a medida que el negocio crezca, es posible que necesites aprovechar un modelo más flexible como el Control de Acceso Basado en Roles (RBAC) o el Control de Acceso Basado en Atributos (ABAC).

También escribí un artículo CIAM 102: Autorización y Control de Acceso Basado en Roles para demostrar los conceptos básicos de autorización y el modelo RBAC.

Tomar la decisión#

Puedes ver que la autenticación no es un problema de "todo o nada", ya que implica múltiples componentes técnicos y tú o tu equipo pueden tener diferentes experticias técnicas en estas áreas. Es importante desglosarlo en partes más pequeñas para obtener una mejor comprensión del estado de la situación.

Para tomar la decisión, me haría las siguientes preguntas:

• ¿Cuán urgente es el proyecto?
• ¿Cuánto esfuerzo espero poner en la autenticación frente al negocio?
• ¿Cuál es la prioridad de la experiencia del usuario, la seguridad y la mantenibilidad?
• ¿De qué parte(s) necesito tener el control total? ¿Cuánto debo familiarizarme con ellas?
• Si opto por algunos marcos / soluciones, ¿son suficientemente buenos para la personalización o extensión?
• Si el negocio crece, ¿necesitaré introducir un nuevo modelo de autenticación?
• Si encuentro un proveedor adecuado, ¿es lo suficientemente seguro para usarlo? ¿Necesito un plan de retiro si le sucede algo al proveedor?

Con las preguntas en mente, descubrí dos hechos:

• Crear un sistema de autenticación confiable es altamente complejo.
• Los proveedores existentes no pueden cumplir con todos los criterios necesarios.

Así que decidí iniciar un proyecto dedicado (Logto) para la autenticación, y abrazar la comunidad de código abierto desde el primer día.

Espero que este artículo te ayude.