Trust a gateway-set identity header only if the gateway removes any client-supplied copy, every call must pass through it, and the service validates who sent it. Better, use a signed assertion from a designated issuer, and still run the service's own object checks.
The risk
A gateway authenticates the caller and then tells downstream services who they are, often through headers like a user ID or tenant. If a service reads those headers without checking where they came from, anyone who can reach the service directly, or who sends the same header through the gateway, can claim any identity.
The OWASP Identity Propagation Patterns Cheat Sheet describes this pattern and its limits. Where a trusted proxy header is used, remove client-supplied copies, authenticate the proxy and prevent requests from bypassing it.
Four ways to carry identity
| Pattern | How it works | Main caution |
|---|---|---|
| Forward the external token | Edge passes the access token to services that are intended recipients | Do not widen the audience just to make forwarding work |
| Service-level forwarding | A service forwards a header or self-signed assertion | Every service trusted to supply attributes can misrepresent them |
| Token exchange | A service trades a token for one for a downstream recipient (RFC 8693) | Adds an issuance dependency, STS must authorize the exchange |
| Normalized internal assertion | Edge validates the external credential and issues an internal one | Keep issuing and verifying privileges separate |
What a service must do
The Authorization Patterns sheet covers propagating a signed context from a gateway. Downstream services must validate:
- The trusted issuer.
- Integrity of the context.
- Audience, meaning it was meant for this service.
- Expiry.
- That it applies to the actual request.
It adds three rules that are easy to skip. Reject direct calls that lack the required context. Strip client-supplied copies of trusted headers before populating them. And remember a signature alone neither prevents bypass nor authorizes a different resource, tenant or action, so keep service-level enforcement.
Why coverage is a deployment requirement
The same sheet says complete traffic coverage is a deployment requirement and not an automatic property of a gateway. Authenticate permitted callers, restrict direct access to services, and cover internal calls and alternate endpoints. A forgotten internal port or a second ingress can sidestep the gateway completely.
It also notes that routing changes after authorization can invalidate an earlier check, so reevaluate if the effective resource or action changes.
A checklist
- Block direct network access to services, except from the gateway or mesh.
- Have the gateway delete inbound copies of every trusted header name, then set its own.
- Prefer a signed assertion with an audience and short expiry over raw headers.
- Validate it in a shared middleware in every service.
- Authorize the action and object in the service, since a valid identity is not permission for everything.
- Never use an ID token as an API access token.
- Send only the identity attributes the recipient needs.
How to test
From inside the network, call a service directly with a forged user header. It must refuse. Through the public edge, send the same header yourself and confirm the gateway overwrites or drops it. Replay a signed assertion against a different service, and expect an audience failure.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how requests with altered headers are tried against an endpoint.
Safeguard supports dependency scanning and reachability analysis for the proxy and token libraries in your services. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a mesh with mutual TLS enough to trust the header?
It proves which service called, not that the service may assert a given user. Keep header stripping, signed context and service-level checks.
Should every service re-verify the original user token?
If each is an intended recipient with a matching audience, yes, that is a valid pattern. Otherwise use a signed internal assertion or token exchange.
Sources
Last reviewed: 19 October 2026.
