Identity propagation passes the initiating user’s identity through a chain of services, even when those services use different programming languages and communication protocols. The user identity differs from service identity: one identifies who started the request, while the other identifies each service acting on that user’s behalf. section 3.1.1 section 3.4
A mixed-protocol call chain
An edge service determines the user’s identity through OIDC or WebAuthn, then passes it over HTTP to a C# service. That service forwards it over gRPC to Go, which continues over AMQP to JavaScript. Each boundary must preserve the identity across different protocols and languages. section 3.1.1
A practical design starts with these constraints:
- Use system-specific patterns and conventions because no industry-standard solution propagates user identity across service calls. section 3.4
- Keep user identity separate from service authentication, which can use API keys or mutual TLS. section 3.5
Figure 3.4 The edge service uses OpenID Connect (OIDC) or WebAuthn protocols to determine the identity of the user making the request. It must then propagate the user identity over HTTP to the service written in C#, which must propagate the user identity over gRPC to the service written in Go, which must propagate the user identity over the Advanced Message Queuing Protocol (AMQP) to the service written in JavaScript.
Follow the identity as it crosses the edge, HTTP, gRPC, and AMQP boundaries. section 3.1.1
