Service identity is a unique, verifiable identity that lets one service prove who it is when calling another. It supports authorization, auditing, and secure communication in zero-trust systems, where internal services are not trusted automatically. section 16.1 section 16.4
When a service name is not proof
Suppose a billing service accepts an X-Service-Name: order-service header without verifying it. An attacker who reaches the network can create fake requests, process invoices, or obtain billing data while impersonating the order service. A secure receiver authenticates the caller and then checks whether that service may perform the requested action. section 16.1
Establish service identity with mechanisms that match the trust boundary and operational needs:
- API keys identify callers through a shared header or message value; gateways can simplify enforcement, but static keys are easy to leak, spoof, and difficult to rotate. section 3.1.2 section 16.4
- Mutual TLS authenticates both services with X.509 certificates and encrypts their connection; it is stronger than ordinary TLS but more complex to configure. section 3.1.2
- Application-level checks provide flexible, fine-grained authorization through tokens, API keys, or signed messages, while infrastructure-level controls provide consistent baseline enforcement. section 16.4 section 16.5
- A mixed model commonly lets gateways or service meshes enforce identity and baseline access while applications enforce business-specific rules. section 16.5
Keep service identity distinct from user identity. A request may carry the initiating user’s identity while also passing through several service identities. Services authorize based on the user, the calling service, or both; user-identity propagation across HTTP, gRPC, and AMQP has no single industry-standard solution. section 3.4 section 3.1.2
