Carlos Fernando Aguilar González
Fernando Fuentes
Gracias amigo.
¿Cuál es el objetivo del segundo reto de este curso?
El segundo reto del curso se centra en la creación de un servicio de autenticación completamente aislado. Este reto surge luego del diseño e implementación del servicio de lectura. El objetivo principal es abstraer el proceso de autenticación como un servicio separado para permitir la escalabilidad del sistema y del negocio. Es fundamental que los participantes elaboren un documento de diseño que detalla la implementación de este servicio y cómo debe funcionar de manera eficiente.
¿Por qué se debe separar el servicio de autenticación?
Separar el servicio de autenticación es crucial para una serie de razones estratégicas y de escalabilidad:
One Service, Multiple Usages: Un servicio de autenticación independiente permite verificar si un usuario está autorizado a realizar ciertas acciones, como subir reseñas, de manera eficiente sin replicar el código en diferentes servicios.
Escalabilidad del negocio: Al separar los servicios, el negocio puede crecer y adaptarse a nuevas necesidades como ofrecer reseñas exclusivas para usuarios registrados o premiar usuarios con accesos especiales.
Mantenimiento simplificado: Tener un solo lugar para gestionar y actualizar el proceso de autenticación reduce errores y facilita la implementación de cambios futuros.
¿Cómo se integraría el servicio de autenticación en sistemas existentes?
La integración de un servicio autónomo de autenticación es una excelente manera de modernizar y hacer más robusto un sistema. A continuación, se describe una forma general de lograr esta integración:
Petición de autenticación externa: Al recibir una petición en el sistema, ya sea a través de una Azure Function o Lambda Function, esta puede enlazar al servicio de autenticación para verificar la validez del usuario.
Verificación del usuario: El servicio evaluará el token o credencial proporcionada y devolverá una respuesta de autenticación positiva o negativa.
Flujo de Acción Basado en Respuesta: Si el usuario es autenticado, el sistema procederá; de lo contrario, bloqueará acciones como la publicación de reseñas.
Adaptación a futuro: El servicio permite adaptarse a potenciales cambios de negocio, como ofrecer contenido premium bajo ciertas condiciones de acceso.
¿Qué beneficios tendría la abstracción de autenticación en un servicio por separado?
Abstraer el servicio de autenticación proporciona múltiples beneficios tanto desde una perspectiva técnica como comercial, incluidos:
Facilidad de escalabilidad: Los sistemas pueden crecer en línea con el negocio, permitiendo la incorporación de funcionalidades sin grandes esfuerzos técnicos.
Reducción de Errores: Minimiza potenciales discrepancias o errores en la implementación de autenticación al centralizar el control en un único servicio.
Personalización y Flexibilidad: Ofrece la oportunidad de diseñar sistemas que se adaptan a diferentes tipos de usuarios, permitiendo características como el acceso a contenido exclusivo únicamente a usuarios autenticados.
Este reto no sólo invita a los participantes a desarrollar habilidades técnicas, sino también a pensar estratégicamente sobre escalabilidad y eficiencia del sistema. Queda como tarea investigar herramientas y metodologías para implementar este sistema de autenticación, con la certeza de que esta experiencia será preparatoria para futuros desafíos en la industria.
Vale, en mi práctica lo plantee de esta forma: . El cliente tiene que autenticarse primero, es decir, tiene que solicitar un token al servidor de autenticación, una vez que tenga listo el token, deberá mandar ese token junto con su solicitud POST (me equivoqué en el diagrama y puse PUT jaja, prometo corregirlo), esta solicitud llegará a un Droplet de Digital Ocean que contendrá la parte de la lógica del API para insertar el dato en mongoDB mediante Node. . Como serán pocos usuarios los que harán POST, basta con un pequeño droplet en Digital Ocean, este servidor primero validará el token, para ello, hará una solicitud de verificación del token al servidor de autenticación. Este servidor dirá si el token es válido o no, y dependiendo de ello, el servidor dará una respuesta al cliente con su solicitud completada o rechazada. . Por último, el servidor de autenticación será manejado mediante Laravel Sanctum que es una dependencia de Laravel encargada de generarar tokens de autenticación y almacenarlos (básicamente el sistema de autenticación ya terminado)
Carlos Fernando Aguilar González
Fernando Fuentes
Gracias amigo.
Marlon García Cedillo
Comparto mi aporte
Capacitacion 2
Hola, que tal? dejo un link de Drive que lleva a la carpeta de la tarea: https://drive.google.com/drive/folders/1T_4hpEiuAvFCyhziCMMEYFSnSTPqoZA6?usp=sharing Gracias, saludos!
Jorge Bou-saad
Para quien le interese, hace un tiempo hice este boilerplate de react para hacer un login con AWS Cognito. Con esta clase, me acorde de ese repositorio que hice en el 2022 (el que guste puede hacerle fork y mejorarlo)
Yeimar Yecid Lemus Romaña
Buenas tardes, este es mi diagrama de arquitectura.
En el centro de mi arquitectura tengo un proxy (traefik) este servicio se encarga de enrutar las peticiones a mis servicios
En el backend tengo una API en el Framework laravel con un escalado horizontal balanceando la carga entre 4 microservicios
Tengo un sistema de cache, para optimizar las peticiones de consulta
Tengo 2 base de datos
MongoDB - Para lectura
PostgreSQL - Para escritura
Sistema de caché
Redis - Optimizacion de las consultas
El front-end de mi arquitectura esta en Vuejs
Fernando Robles
Acá debería ser autorización. Puedes estar autenticado pero no tener autorización(roles)
Juan David Forero
Estaba pensando en lo mismo justamente.
Gonzalo Peñaranda
Con lo que se menciona del token, esta validación añade capas adicionales de seguridad, además de que se revisa constantemente si la sesión del usuario sigue vigente cuando se va a realizar alguna actividad.