Microservices security
Keep service identity, propagated user context, and resource authorization distinct across gateways and internal service calls.
What it means
Microservices security distributes identity, authorization, and data protection across services with different responsibilities. Gateway controls are useful but do not automatically protect internal operations. Each service needs a clear policy for the caller, propagated user context, and the action it performs.
A practical example
An order service calls a billing service with a verified service identity and constrained operation data. Billing does not trust an arbitrary user ID forwarded in a header; it applies its own authorization requirements before exposing or modifying records.
What to check
Map service identities, user-context propagation, data ownership, and gateway bypass paths. Secure service-to-service transport and document which component enforces each operation's final authorization decision.
A common pitfall
Trusting every request from an internal service can turn that service into a confused deputy. Network location alone does not prove that the original user is authorized.
Think it through
Why enforce policy in the billing service as well as the gateway?
Answer: Internal callers, alternate routes, and compromised services can reach the operation without the intended gateway checks.
Follow the authority through the call chain
Imagine a fictional academy's portal calls a progress service, which calls a reporting service. The gateway authenticates the learner, but each downstream operation still needs enough trusted context to decide whether the requested record is permitted.
A caller-supplied header saying “administrator” is not a trustworthy identity assertion. Define how user context is validated and how the calling service itself is authenticated. Those identities answer different questions: who initiated the work and which component is making this call.
A trusted service can become an overpowered deputy
Suppose the progress service has broad reporting access. If it accepts an arbitrary learner identifier and forwards it without checking the original caller's rights, it can misuse its own authority on someone else's behalf.
The reporting service should enforce the relevant resource and tenant policy at its boundary. Gateway checks can reduce exposure, but alternate internal paths and compromised callers are reasons to keep the final business decision explicit.
Distributed systems need shared evidence
A request can cross several logs and retry paths. Correlation identifiers help link events, but they should not carry secrets or become authorization credentials. Record enough service and user context to investigate a denial or unexpected data access.
Policy updates, token expiration, and dependency outages also need defined behavior. A cached permission decision may remain valid longer than intended if freshness requirements are unspecified.
For a paper exercise, trace one authorized report request through three services. Label the authenticated service at each hop, the original user context, and the component that decides record access. Then replace the requested record with one belonging to another learner. Explain exactly which boundary rejects it and what evidence confirms the rejection. This tests the actual authority chain rather than assuming all internal requests inherit legitimacy from the network.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Microservices Security