What is Identity Propagation?
Identity propagation carries verified information about the originating principal and, when needed, the acting service across request boundaries. It avoids replacing all callers with one shared identity.
Why it matters
A downstream service needs reliable caller context to apply user-specific policy and create useful audit records. Loss of that context can grant broad shared access or hide accountability.
How it works
- Authenticate the originating principal.
- Mint or exchange a target-specific signed assertion that retains the needed subject and actor context.
- At the downstream service, validate the signature, issuer, audience, expiry, and authorization data before use.
Example
Alice asks an agent to query an inventory service. The request reaches the service with verified user context for Alice and separate context for the acting application.
Pomerium boundary
Pomerium mints a signed JWT from verified identity claims and passes it to an upstream application. The upstream must validate its signature, issuer, audience, and expiry. The Pomerium identity assertion does not contain the original IdP token. An operator can separately configure a route to send an available IdP access token or ID token in an upstream request header.
Limits and non-claims
- Copying an unsigned identity header is not verified identity propagation.
- Propagated identity does not make downstream authorization correct.
- Services must minimize identity data and avoid sending a credential to the wrong audience.
Evaluation checklist
- Does each hop preserve the originating actor, active subject, issuer, audience, and trust source?
- How does the receiver verify freshness and prevent a client from supplying the identity assertion?
- Does the application map the propagated identity to its own resource and action authorization?
