Fluxo de login

Fluxo end-to-end de autenticação: desde o formulário no frontend, passando pelo BFF e pelo serviço de Auth, até a emissão do JWT e a resposta ao cliente.

O login é provavelmente o primeiro fluxo que qualquer usuário executa em uma aplicação. É também um dos mais sensíveis: envolve credenciais, tokens de segurança e decisões de acesso que afetam todo o sistema.

Entender como o login flui através da arquitetura ajuda a enxergar como as camadas colaboram para resolver um caso real de ponta a ponta.

O fluxo passo a passo

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

O que cada camada faz

Frontend

Exibe o formulário de login
Valida se o email tem o formato correto e se a senha não está vazia
Envia as credenciais por HTTPS ao API Gateway
Recebe os tokens e os armazena (geralmente em memória ou em um cookie httpOnly)
Redireciona o usuário para a página principal

Importante: o frontend nunca armazena a senha. Ele apenas a envia uma vez e trabalha com tokens a partir desse momento.

API Gateway

Recebe a requisição de login (essa rota não requer token prévio)
Aplica rate limiting para prevenir ataques de força bruta
Registra a tentativa de login no log de acesso
Roteia para o BFF

BFF

Recebe as credenciais
Invoca o serviço de autenticação
Se a autenticação for bem-sucedida, transforma a resposta no formato que o frontend espera
Se falhar, retorna um erro genérico (sem revelar se o email existe ou não)

Auth Service

Este é o microsserviço especializado em identidade e acesso:

Busca o usuário por email no banco de dados
Se não existir, retorna erro de credenciais inválidas
Se existir, compara o hash da senha armazenada com a senha recebida
Se coincidir, gera um par de tokens JWT:
- Access token: vida curta (15–30 minutos), contém claims do usuário
- Refresh token: vida mais longa (7–30 dias), permite renovar o access token
Retorna os tokens e os dados básicos do usuário (nome, papel, permissões)

Banco de dados de usuários

Armazena os dados do usuário, incluindo:

Email (único)
Hash da senha (nunca a senha em texto plano)
Papel e permissões
Estado da conta (ativa, bloqueada, pendente de verificação)
Metadados (último login, tentativas malsucedidas)

Estrutura do JWT

O access token JWT normalmente contém:

{
  "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"
  }
}

O token é assinado com uma chave privada que somente o Auth Service conhece. Qualquer serviço pode verificar a assinatura com a chave pública correspondente.

Fluxo de renovação do token

Quando o access token expira, o frontend usa o refresh token para obter um novo sem pedir credenciais novamente:

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

Cenários de erro

Credenciais incorretas

O Auth Service retorna um erro genérico: “Credenciais inválidas”. Não se indica se o email existe ou não, para evitar a enumeração de usuários.

Conta bloqueada

Após N tentativas malsucedidas (normalmente 5), a conta é bloqueada temporariamente. O serviço retorna um erro indicando que a conta está bloqueada e quando é possível tentar novamente.

Token expirado

O frontend detecta um 401 em qualquer requisição posterior e automaticamente tenta renovar o token com o refresh token. Se o refresh token também tiver expirado, redireciona para o login.

Serviço de Auth indisponível

Se o Auth Service estiver fora do ar, o BFF retorna um 503. O frontend exibe uma mensagem de “serviço temporariamente indisponível” e permite tentar novamente.

Considerações de segurança

As senhas são transmitidas apenas por HTTPS
São armazenadas como hash com salt (bcrypt, argon2)
Os tokens têm expiração curta
O refresh token pode ser revogado a partir do servidor
O rate limiting protege contra força bruta
Os erros não revelam informações sobre a existência de contas

Resumo

O fluxo de login demonstra como todas as camadas da arquitetura colaboram para resolver um caso de uso crítico. Cada camada tem uma responsabilidade clara: o frontend cuida da experiência do usuário, o Gateway protege a entrada, o BFF orquestra e transforma, e o Auth Service gerencia a identidade. A segurança não é um acréscimo posterior, mas parte integral do design do fluxo.