Flujo de login

Flujo end-to-end de autenticación: desde el formulario en el frontend, pasando por el BFF y el servicio de Auth, hasta la emisión del JWT y la respuesta al cliente.

El login es probablemente el primer flujo que cualquier usuario ejecuta en una aplicación. Es también uno de los más sensibles: involucra credenciales, tokens de seguridad y decisiones de acceso que afectan a todo el sistema.

Entender cómo fluye el login a través de la arquitectura ayuda a ver cómo las capas colaboran para resolver un caso real de principio a fin.

El flujo paso a paso

sequenceDiagram
    participant U as Usuario
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant AUTH as Auth Service
    participant DB as Users DB

    U->>FE: Ingresa email y contraseña
    FE->>FE: Validación básica del formulario
    FE->>GW: POST /auth/login
    GW->>GW: Rate limiting, logging
    GW->>BFF: Forward request
    BFF->>AUTH: Verificar credenciales
    AUTH->>DB: Buscar usuario por email
    DB-->>AUTH: Datos del usuario
    AUTH->>AUTH: Verificar hash de contraseña
    AUTH->>AUTH: Generar JWT (access + refresh)
    AUTH-->>BFF: Tokens + datos básicos del usuario
    BFF-->>GW: Respuesta formateada para UI
    GW-->>FE: 200 OK + tokens
    FE->>FE: Almacenar tokens, redirigir
    U->>FE: Ve el dashboard

Qué hace cada capa

Frontend

Muestra el formulario de login
Valida que el email tenga formato correcto y que la contraseña no esté vacía
Envía las credenciales por HTTPS al API Gateway
Recibe los tokens y los almacena (generalmente en memoria o en una cookie httpOnly)
Redirige al usuario a la página principal

Importante: el frontend nunca almacena la contraseña. Solo la envía una vez y trabaja con tokens a partir de ese momento.

API Gateway

Recibe la petición de login (esta ruta no requiere token previo)
Aplica rate limiting para prevenir ataques de fuerza bruta
Registra el intento de login en el log de acceso
Enruta al BFF

BFF

Recibe las credenciales
Invoca al servicio de autenticación
Si la autenticación es exitosa, transforma la respuesta al formato que el frontend espera
Si falla, devuelve un error genérico (sin revelar si el email existe o no)

Auth Service

Este es el microservicio especializado en identidad y acceso:

Busca al usuario por email en la base de datos
Si no existe, devuelve error de credenciales inválidas
Si existe, compara el hash de la contraseña almacenada con la contraseña recibida
Si coincide, genera un par de tokens JWT:
- Access token: vida corta (15–30 minutos), contiene claims del usuario
- Refresh token: vida más larga (7–30 días), permite renovar el access token
Devuelve los tokens y datos básicos del usuario (nombre, rol, permisos)

Base de datos de usuarios

Almacena los datos del usuario incluyendo:

Email (único)
Hash de la contraseña (nunca la contraseña en texto plano)
Rol y permisos
Estado de la cuenta (activa, bloqueada, pendiente de verificación)
Metadata (último login, intentos fallidos)

Estructura del JWT

El access token JWT típicamente contiene:

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user-123",
    "email": "usuario@ejemplo.com",
    "role": "admin",
    "permissions": ["read:orders", "write:orders"],
    "iat": 1705312200,
    "exp": 1705314000,
    "iss": "auth-service"
  }
}

El token está firmado con una clave privada que solo el Auth Service conoce. Cualquier servicio puede verificar la firma con la clave pública correspondiente.

Flujo de renovación del token

Cuando el access token expira, el frontend usa el refresh token para obtener uno nuevo sin pedir credenciales de nuevo:

sequenceDiagram
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant AUTH as Auth Service

    FE->>GW: POST /auth/refresh (refresh token)
    GW->>BFF: Forward
    BFF->>AUTH: Validar refresh token
    AUTH->>AUTH: Verificar firma y expiración
    AUTH->>AUTH: Generar nuevo access token
    AUTH-->>BFF: Nuevo access token
    BFF-->>GW: Respuesta
    GW-->>FE: 200 OK + nuevo access token

Escenarios de error

Credenciales incorrectas

El Auth Service devuelve un error genérico: “Credenciales inválidas”. No se indica si el email existe o no, para evitar enumeración de usuarios.

Cuenta bloqueada

Después de N intentos fallidos (típicamente 5), la cuenta se bloquea temporalmente. El servicio devuelve un error indicando que la cuenta está bloqueada y cuándo se puede reintentar.

Token expirado

El frontend detecta un 401 en cualquier request posterior y automáticamente intenta renovar el token con el refresh token. Si el refresh token también expiró, redirige al login.

Servicio de Auth no disponible

Si el Auth Service está caído, el BFF devuelve un 503. El frontend muestra un mensaje de “servicio temporalmente no disponible” y permite reintentar.

Consideraciones de seguridad

Las contraseñas se transmiten solo por HTTPS
Se almacenan como hash con salt (bcrypt, argon2)
Los tokens tienen expiración corta
El refresh token se puede revocar desde el servidor
Rate limiting protege contra fuerza bruta
Los errores no revelan información sobre la existencia de cuentas

Resumen

El flujo de login demuestra cómo todas las capas de la arquitectura colaboran para resolver un caso de uso crítico. Cada capa tiene una responsabilidad clara: el frontend maneja la experiencia del usuario, el Gateway protege la entrada, el BFF orquesta y transforma, y el Auth Service gestiona la identidad. La seguridad no es un añadido posterior sino parte integral del diseño del flujo.