How to centralize permissions across microservices
What goes wrong when authorization is scattered across microservices, and how a central permission model improves security and maintenance.
Microservices multiply the authorization surface: each service can interpret roles differently, duplicate permission lists, or trust forged headers. Centralizing permissions does not mean an auth monolith. It means one source of truth for identity and policy, with consistent checks at the edge and in the services.
Symptoms of scattered authorization
- Service A accepts ADMIN; Service B only knows ROLE_ADMIN
- A new permission requires a deploy in eight repositories
- The gateway authenticates; the internal service blindly trusts X-User-Id
- Audit is impossible — “who authorized this?”
Patterns that work
A propagated token (JWT)
The gateway validates the JWT; downstream services revalidate the signature or receive the forwarded token over internal mTLS. Claims carry permissions — they are not invented locally.
An external policy decision point
Services ask a PDP (OPA, an IAM) whether the action is allowed. More flexible, more latency — use a short-TTL cache.
IAM plus an SDK per language
Gatekeeper or Keycloak issues the token; a Spring Boot, Go, or Node SDK applies the same permission semantics in every JVM service.
When to centralize
- From three or more services with human users
- Compliance requires a single trail of who can do what
- Multi-tenant with different RBAC per customer
Common mistakes
- Auth only at the API gateway — the internal network is “trusted” until it is not
- Manually syncing a CSV of roles between teams
- Permissions in each service’s database, diverging from the IAM
- An opaque token with no standard introspection
How Gatekeeper ID helps
One console for roles and permissions per tenant; a JWT with standardized claims; an SDK to validate in each Spring Boot service. New microservices inherit the same model — onboarding is configuration, not a rewrite of auth.
See RBAC in Java and multi-tenant authentication.
Conclusion
Centralized authorization scales the organization, not only the infrastructure. Invest early in IAM and in the token contract — or pay interest in incidents and synchronized deploys.