Service-oriented authorization requires each independently deployed service to decide whether a request is allowed. A successful upstream check is not enough: network requests may arrive from an untrusted frontend or service, so every service must validate authorization for the resources it owns. section 17.2.2
Common approaches distribute authorization in different ways:
- RBAC checks roles embedded in identity tokens, but role meanings can drift between services. section 17.2.2
- ABAC evaluates claims such as department, region, or clearance level, provided services agree on their meanings and sources. section 17.2.2
- ReBAC queries a central relationship store, such as OpenFGA or a custom authorization engine, to evaluate user-resource relationships. section 17.2.2
Figure 17.5 Enriching authorization claims across system layers. The IdP issues a token with basic claims, such as roles or user ID. The API Gateway can enhance the token with request-specific claims, such as active project IDs or request origin. Finally, backend services (such as the order service) might fetch additional business-specific data, such as user preferences, access scope, and customer assignments, from a profile service or a custom authorization component. This layered enrichment ensures that services receive the right context to make fine-grained authorization decisions.
Claims can be enriched progressively: identity providers issue basic identity or role claims, gateways add request context, and backend services obtain business-specific access data. section 17.2.2
Centralized relationship checks improve consistency but add dependency risk. If the relationship store becomes unavailable, otherwise healthy services may be unable to validate access; high availability or fallbacks are therefore essential. section 17.2.2
