User identity answers: who initiated this request chain? Usually that entity is a customer, employee, or partner, but it can also be an API consumer acting for itself. Identity matters because secure applications must make design choices about identity, authentication, and authorization rather than treat every request as anonymous. section 1.4 section 3.4
A request may carry more than one identity. The user identity identifies the original requester; service identity identifies each application making calls on that user’s behalf. An edge service might receive a customer request and call an internal order or billing service, creating a chain that must preserve both kinds of identity. section 3.4
The practical difficulty is propagation. Services may use different programming languages and protocols, such as HTTP, gRPC, and AMQP. There is no industry-standard way to propagate user identity across all such calls, so systems rely on internal patterns and conventions. section 3.4
When a request identity cannot be trusted
An internal billing service accepts a header such as X-Service-Name: order-service without verifying the sender. An attacker can copy the header, impersonate the order service, submit fake invoices, and expose billing data. The safer design distinguishes the claimed identity from authentication: identity says who the caller claims to be; authentication checks whether that claim is true. section 16.1 section 16.4
For user-facing login, OpenID Connect adds authentication to OAuth 2. Its ID token carries user identity information such as an email or name, while OAuth 2 addresses what the client may access. Tenant-specific claims can keep users separated in multitenant systems. section 13.5
