How do I manage authorization across microservices?

Managing authorization across microservices is usually easiest when you centralize policy decisions but decentralize enforcement.

Core approaches

1) Put authorization at the edge

Use an API gateway or BFF to handle coarse-grained checks like:

• is the user authenticated?
• does the user have access to this API?
• rate limits / tenant checks

This reduces duplication, but it should not be the only layer.

2) Enforce authorization inside each service

Each microservice should verify:

• the caller’s identity
• the caller’s scopes/roles/claims
• any resource-specific rules

This is important because services should not trust the gateway alone.

3) Use centralized policy management

Keep authorization logic in a shared policy system or service:

• RBAC for simple role-based access
• ABAC for attribute-based rules
• OPA / Open Policy Agent, Cedar, or a custom policy engine for complex cases

Services ask the policy engine: “Can user X do action Y on resource Z?”

4) Pass user identity securely between services

When service A calls service B, avoid using only a static service token if the request is user-specific. Common patterns:

• Token forwarding / token exchange: propagate the user context downstream
• On-behalf-of flow: service gets a downstream token representing the user
• Service-to-service credentials: for purely backend actions not tied to a user

5) Use JWTs carefully

JWTs are common because services can validate them locally, but:

• keep them short-lived
• include only necessary claims
• avoid putting sensitive data in them
• plan for key rotation and revocation strategy

For higher control, use opaque tokens plus introspection.

Practical architecture

A common setup looks like this:

1. User authenticates with an identity provider
2. API gateway validates the access token
3. Gateway forwards request to service A
4. Service A validates token and checks policy
5. If A needs data from B:
   • A either forwards the user context, or
   • uses token exchange to get a downstream token
6. Service B validates the caller and applies its own authorization rules

Best practices

• Least privilege: give only the permissions needed
• Deny by default
• Separate authentication from authorization
• Model permissions around business actions, not just endpoints
• Use service identities for internal service-to-service calls
• Log authorization decisions for auditability
• Make policies versioned and testable

Common mistakes

• Relying only on gateway authorization
• Encoding too much business logic in JWT claims
• Using shared DB tables for all permission checks
• Hardcoding permissions in many services
• Not considering multi-tenancy / resource ownership

Rule of thumb

• Simple system: RBAC in each service + gateway checks
• Medium/large system: centralized policy engine + local enforcement
• Highly regulated system: token exchange, short-lived tokens, audit logs, fine-grained ABAC

If you want, I can also show:

1. a reference architecture diagram,
2. an OPA-based example, or
3. a JWT/token-exchange flow for service-to-service authorization.