Construyendo una aplicación Potenciada por Cursor Devlog Parte 4 Autenticación: en esta entrega repasamos la lógica de autenticación que protege nuestras APIs y habilita sesiones seguras para usuarios.
En el dominio de autenticación las piezas principales son las credenciales y la sesión. La credencial representa la entrada necesaria para iniciar sesión: email y contraseña. La sesión es el resultado exitoso del inicio de sesión y contiene dos tokens: access_token y refresh_token.
La responsabilidad del dominio de autenticación es la lógica de negocio: validar credenciales, generar tokens JWT, gestionar la lógica de refresh y revocar tokens. Todo esto se realiza sin depender de HTTP ni formatos de transporte para mantener un dominio puro y testeable.
Definición práctica de Credencial: campos email y password validados antes de cualquier proceso. Buenas prácticas: no almacenar credenciales, validar ambos campos y verificar la contraseña contra el hash almacenado del usuario. El método Verify compara la contraseña proporcionada con la contraseña cifrada del usuario y devuelve error si no coinciden.
Objeto Sesión: incluye AccessToken y RefreshToken. AccessToken se usa para acceso a APIs por un periodo corto, RefreshToken para obtener nuevos access tokens. Se recomienda implementar rotación de refresh tokens para mayor seguridad y evitar exponer detalles sensibles en logs.
Generamos dos tokens y almacenamos su metadata en Redis para tener control total del ciclo de vida de cada token. El objeto Sesión contiene metadatos como exp expiración, nbf not before, jti identificador único, user_id identificador del usuario y link_id que enlaza un access token con su refresh token para revocación conjunta.
Los tokens tienen reglas de tiempo: el access_token es de corta duración por ejemplo 2 horas; el refresh_token dura más por ejemplo 48 horas y puede estar bloqueado los primeros 2 horas mediante nbf para evitar refrescos prematuros.
Claves de almacenamiento en Redis: access:jti y refresh:jti que apuntan a los metadatos correspondientes. Gracias a Redis podemos revocar tokens instantáneamente; si se elimina la entrada asociada, el token deja de ser válido en la siguiente petición.
Por qué importa esta arquitectura: permite aplicar expiración y not before, revocación inmediata, revocar ambos tokens usando link_id y evitar confiar a ciegas en tokens del cliente. Cada token se valida contra Redis para mayor seguridad.
Casos de uso implementados: login, refresh token y logout. En el login se reciben email y password y se comprueban frente a un usuario temporal hardcodeado para pruebas. Si la validación es correcta se emite un par de tokens: access y refresh con sus tiempos configurados.
En refresh token la API recibe el refresh token, valida nbf y exp, emite un nuevo par de tokens y revoca el refresh token antiguo para hacerlo de uso único, mitigando el riesgo de reutilización por un atacante.
En logout la API recibe el access token desde el header Authorization Bearer, revoca el access token y usa link_id para localizar y revocar el refresh token asociado, garantizando que ambos tokens queden inutilizables.
Para el ensamblado de dependencias usamos Google Wire como herramienta de inyección de dependencias. Con Wire definimos un conjunto UseCaseSet que agrupa configuración, cliente Redis, adaptador Redis, repositorios, generador de tokens y los casos de uso de autenticación. Wire construye el contenedor final que facilita testing y evita cableado manual de dependencias.
Ventajas de este enfoque: elimina el wiring manual de dependencias, facilita pruebas cambiando implementaciones por mocks, evita dependencias ocultas y mantiene el sistema modular y mantenible. UseCaseSet es el plano y Wire el constructor que produce un contenedor listo para usar.
Este devlog usa por ahora un usuario hardcodeado solo para acelerar la demostración. La mecánica de tokens ya es de estilo producción y cuando integremos la base de datos la autenticación pasará a validar usuarios reales manteniendo la misma lógica de sesiones y revocación basada en Redis.
En Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida. Ofrecemos experiencia en inteligencia artificial, ia para empresas, agentes IA, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y soluciones con power bi. Integramos seguridad, rendimiento y buenas prácticas para entregar productos escalables y alineados con objetivos de negocio.
Si buscas integrar autenticación robusta en tus proyectos o desarrollar aplicaciones a medida con capacidades de inteligencia artificial y ciberseguridad, en Q2BSTUDIO diseñamos arquitecturas seguras con sesiones controladas, rotación de refresh tokens y visibilidad operativa mediante almacenamiento en Redis y monitoreo de servicios cloud aws y azure.
Palabras clave para mejorar posicionamiento: aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio ia para empresas agentes IA power bi.
Próximos pasos: llevar esta capa de autenticación al nivel de presentación. Los endpoints REST y la documentación con Swagger permitirán que el mundo exterior consuma nuestros servicios de forma segura, mientras seguimos reforzando aspectos como auditoría, métricas y soporte para múltiples proveedores cloud.
En resumen, con una capa de autenticación basada en sesiones, tokens JWT y almacenamiento en Redis, más un contenedor de dependencias construido con Wire, obtenemos un sistema modular, seguro y listo para integrarse en aplicaciones a medida y soluciones de inteligencia artificial ofrecidas por Q2BSTUDIO.
.jpg)
.jpg)
.jpg)
