A Autenticação em Microserviços Está Te Sabotando (E Você Nem Percebeu)

1. Onde o Dev Se Queima: O Labirinto Invisível da Autenticação

Microserviços não quebram por falta de Kubernetes. Eles quebram por causa da autenticação jogada de qualquer jeito. O time cria 12 serviços, cada um com sua stack, e vira uma colcha de retalhos de JWT expirado, refresh mal implementado e validações inconsistentes.

O pior é simples: cada hop entre serviços aumenta risco, latência, estado compartilhado e vazamento de contexto.

Segundo recomendações da AWS, quando você distribui responsabilidades entre serviços, também distribui potenciais pontos de ataque. A Azure reforça que microserviços exigem governança forte, ou o sistema vira um Frankenstein distribuído.

Traduzindo: se você não centraliza autenticação, você perde controle.

2. O Caminho Sênior: Centralize Antes Que Vire Caos

Quer resolver? Pare de inventar moda. O padrão é claro: OAuth2 + OpenID Connect + Gateway único. Tudo passa por ele. Sem exceção.

O API Gateway vira o porteiro do condomínio: valida, autentica, renova tokens quando necessário e repassa para o serviço interno somente o que ele precisa saber.

Microserviço não deveria saber qual é o provedor de identidade. Ele só deve confiar no gateway.

3. Implementação de Sênior: Autenticação Centralizada na Prática

Abaixo um exemplo direto usando um API Gateway com validação JWT e propagação de identidade para os serviços internos:

# Exemplo usando Kong + OIDC plugin (kong.yml simplificado)
_format_version: "3.0"

auth_service:
  plugins:
    - name: oidc
      config:
        issuer: "https://accounts.example.com"
        client_id: "api-gateway"
        client_secret: "s3cr3t"
        introspection_endpoint: "https://accounts.example.com/oauth/introspect"
        bearer_only: "yes"
  routes:
    - name: protected-route
      paths:
        - /orders
      service: orders_service

services:
  - name: orders_service
    url: http://orders.internal.svc:8080

Fluxo operacional:

1. O cliente pega o JWT no seu IdP (Auth0, Cognito, Keycloak etc).
2. O gateway valida o token e enriquece cabeçalhos internos (`X-User-ID`, `X-Roles`).
3. O microserviço NÃO valida o token — ele apenas confia no gateway.

Esse é o ponto: controle central gera segurança real.

Direto das Trincheiras

1. **Nunca** deixe microserviço validar token diretamente do cliente. Isso cria comportamentos divergentes e brechas.
2. Monitore a cadeia completa: falha de autenticação precisa aparecer no observability stack, não no log perdido do microserviço.
3. Padronize o payload do usuário em um header único. Evite passar claims inteiros — menos dados, menos risco.

4. O Preço da Escolha: Quando Centralizar (Ou Não) Destrói Seu Projeto

Centralizar autenticação tem custos claros:

– Gateway vira SPOF se você não fizer HA direito.
– Mais tráfego, mais latência.
– Exige maturidade em segurança e CI/CD bem cuidado.
– Auditoria e compliance precisam ser alinhados.

Agora o outro lado: se você NÃO centraliza, o custo explode exponencialmente. Tokens inconsistentes, duplicação de lógica, múltiplos pontos de falha e uma postura de segurança frágil — exatamente o que a AWS CAF alerta como risco de complexidade não controlada.

A escolha é simples: pagar o preço do controle ou pagar o preço do caos.

Fontes

Recomendações da AWS – Integração de microsserviços usando …, Estilo da arquitetura de microsserviços – Azure Architecture Center …, AWS Orientação prescritiva – AWS Estrutura de adoção da nuvem …

Obrigado por acompanhar essa reflexão até o fim!

Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros “hypes” da nossa área.

Valeu e até a próxima! 😉

Kafka vs RabbitMQ: a verdade nua sobre escalabilidade em microserviços

Chega de romantizar mensageria. Quando o sistema começa a chiar, fila travando e consumidor engasgando, é aí que o arquiteto leva culpa. Kafka e RabbitMQ não são mágicos, têm propósitos distintos — e escolher errado vira dívida técnica que assombra por anos. Neste artigo, trago a visão de trincheira: onde cada um brilha, onde cada um quebra, e quando abandonar o hype e focar no que realmente resolve o problema do negócio.

Banco de dados

Mensageria em Microssistemas: Quando Ela Entrega Valor — e Quando Só Aumenta Sua Dívida Técnica

A verdade nua e crua: muita gente coloca mensageria em microserviços porque viu num diagrama bonito no slide do arquiteto da moda. Só que hype não paga boleto — e muito menos salva sistema mal modelado. Aqui eu explico onde a mensageria realmente resolve dor de negócio, quando ela vira over-engineering e como implementar sem transformar sua stack em um zoológico distribuído impossível de manter.

Discussões

A Ilusão do Low‑Code: Quando a Promessa de Velocidade Destrói Sua Arquitetura

Low‑code funciona… até o dia em que você precisa entender o que realmente está acontecendo lá dentro. Como arquiteto nas trincheiras, já vi mais projetos ruírem por dependência cega em plataformas mágicas do que por falta de framework moderno. Neste artigo, vou direto à dor: o low‑code vende eficiência, mas frequentemente entrega dívida técnica embrulhada para presente. Hora de desmontar o hype e mostrar onde ele realmente funciona — e onde vira armadilha arquitetural.