Como centralizar permissões em microsserviços

Microsserviços multiplicam superfície de autorização: cada serviço pode interpretar roles diferente, duplicar listas de permission ou confiar em headers forjados. Centralizar permissões não significa um monólito de auth — significa uma fonte de verdade para identidade e políticas, com validação consistente na borda e nos serviços.

Sintomas de autorização espalhada

• Service A aceita ADMIN; Service B só conhece ROLE_ADMIN
• Permissão nova exige deploy em 8 repositórios
• Gateway faz auth; serviço interno confia cegamente no X-User-Id
• Auditoria impossível — "quem autorizou isso?"

Padrões que funcionam

Token propagado (JWT)

Gateway valida JWT; serviços downstream revalidam assinatura ou recebem token forwardado via mTLS interno. Claims carregam permissions — não inventadas localmente.

Policy Decision Point externo

Serviços perguntam a um PDP (OPA, IAM) se a ação é permitida. Mais flexível, mais latência — use cache com TTL curto.

IAM + SDK por linguagem

Gatekeeper/Keycloak emite token; SDK Spring Boot, Go ou Node aplica mesma semântica de permission em todos os serviços JVM.

Quando centralizar

• A partir de 3+ serviços com usuários humanos
• Compliance exige trilha única de quem pode o quê
• Multi-tenant com RBAC diferente por cliente

Erros comuns

• Auth só no API Gateway — rede interna "confiável" até não ser
• Sync manual de CSV de roles entre times
• Permissions no banco de cada serviço, divergindo do IAM
• Token opaco sem introspection padronizada

Como o Gatekeeper ID ajuda

Console único para roles/permissions por tenant; JWT com claims padronizados; SDK para validar em cada serviço Spring Boot. Novos microsserviços herdam o mesmo modelo — onboard é configuration, não reescrita de auth.

Veja RBAC em Java e multi-tenant authentication.

Conclusão

Autorização centralizada escala organização, não só infra. Invista cedo em IAM e contrato de token — ou pague juros em incidentes e deploys sincronizados.