How do I manage authorization across microservices?

Managing authorization across microservices requires moving away from traditional, monolithic, session-based code and separating your authentication (identifying who a user is) from your authorization (determining what they are allowed to do). The industry standard approach follows a centralized authentication, decentralized authorization pattern using tokens and policy engines.1. The Core Architecture PatternTo manage authorization at scale without creating tight coupling or network bottlenecks, your systems should be divided into specific functional zones:The Edge Layer (API Gateway): The gateway sits at the perimeter and handles authentication. It intercepts incoming client credentials, exchanges them with an Identity Provider (like Keycloak or Okta) for a cryptographically signed, stateless JSON Web Token (JWT), and strips out raw client credentials. The Token Context Wrapper: The gateway forwards this JWT downward into the internal microservice mesh. The token serves as a lightweight packet carrying user identity, global access groups, and core OAuth scopes. Policy Enforcement Points (PEP): Each individual microservice acts as an independent enforcement boundary. The microservice parses the public key of the Identity Provider to locally verify that the incoming token hasn't been tampered with and checks the scopes before fulfilling the database request. 2. How to Implement Fine-Grained AuthorizationWhile checking basic OAuth scopes at the microservice level handles coarse access ("Can this token read user data?"), enterprise apps frequently require Fine-Grained Access Control (FGAC)—such as determining if a specific user can edit a specific document inside a specific team folder.Exposing complex business access logic inside your raw service code is an architectural anti-pattern. Instead, you should decouple your logic using specialized policy engines:Attribute-Based Access Control (ABAC): Rather than just checking fixed roles, look at dynamic attributes (e.g., "Allow access if the user's country matches the resource's country, AND the time is between 9 AM and 5 PM").Externalized Policy Decision Points (PDP): Run a dedicated sidecar or lightweight microservice daemon (like Open Policy Agent (OPA) or SpiceDB) right alongside your core business microservices.Declarative Rego/AuthZed Policies: You write access policies in a declarative language and save them to Git. When an internal microservice receives a request, it makes a lightning-fast local localhost query to its OPA sidecar: "Can User X execute action Y on Resource Z?" The sidecar returns a simple boolean true or false based on the active Git policy, keeping the underlying business microservice clean.3. Securing Internal Service-to-Service Communication ("East-West" Traffic)Just because an API request is originating from inside your corporate cloud firewall does not mean it should be implicitly trusted. To enforce a complete zero-trust architecture, you must govern internal microservice interactions:Enforce mutual TLS (mTLS): Utilize a service mesh layer (such as Istio, Linkerd, or Cilium) to encrypt all inter-service communications automatically. This ensures Service A can physically verify the cryptographic identity of Service B before accepting packets. OAuth 2.0 Client Credentials Grant: For automated system actions that happen completely in the background without a human user present, services must authenticate using their own specific system machine tokens.Granular Service Scopes: Define tight, specific service scopes. For example, the shipping-service should be scoped exclusively to call the inventory-service to read stock levels, but should be strictly denied access if it attempts to query the payment-billing-service. 4. Technical Best Practices for ProductionNever Re-validate Tokens via Network Requests: Do not force your internal microservices to hit a central authorization server on every single database operation; this creates a single point of failure and drastically increases latency. Services must validate tokens locally using public key cryptography (JWKS). Implement Short Token Lifespans: Because stateless JWTs cannot be trivially revoked mid-flight without complex global cache infrastructure, keep access token lifespans short (e.g., 5 to 15 minutes). Require clients to rotate access tokens using secure, stateful refresh tokens managed at the API Gateway boundary.Sanitize Context Propagation: When passing user details between services via HTTP headers (e.g., X-User-ID), ensure that only the outer API Gateway can create or mutate these headers. Internal services must drop or ignore unverified header attributes originating from the outside world to avoid identity spoofing.