What is Signed Header?
Pomerium's signed header is the X-Pomerium-Jwt-Assertion header. After authorization, Pomerium creates and signs a short-lived JWT and sends it to the upstream application. The application validates the JWT signature and its issuer, audience, and time claims with Pomerium's public key. This is not the same as a browser signing arbitrary HTTP headers, and a digital signature is not encrypted with the private key. The upstream must prevent direct traffic that can bypass Pomerium or strip untrusted copies of the header.
Why it matters
Many upstream applications need verified user context after Pomerium authorizes a request. A signed assertion lets the application detect changed identity claims instead of trusting an unsigned header.
How it works
- Pomerium authenticates and authorizes the request, then creates a short-lived JWT from the approved identity context.
- Pomerium signs the JWT and sends it to the upstream application in X-Pomerium-Jwt-Assertion.
- The application validates the signature, issuer, audience, and time claims before it uses any claim.
Example
An internal dashboard validates X-Pomerium-Jwt-Assertion and uses the verified email and group claims to select the correct tenant view.
Pomerium boundary
Pomerium creates the signed JWT assertion after it authorizes a proxied request. Pomerium publishes verification keys, but the upstream application must validate the assertion and must reject traffic that bypasses Pomerium.
Limits and non-claims
- A signed assertion cannot protect an upstream service that remains directly reachable through a bypass path.
- The JWT is signed, not encrypted, so applications must avoid exposing or logging sensitive claims.
- Incorrect issuer, audience, time, signature, or key-rotation handling can make validation unsafe.
Evaluation checklist
- Which canonical bytes, algorithm, key, audience, and time values does the signature cover?
- Does the trusted proxy remove every client-supplied copy before it sets the header?
- Does the upstream validate authenticity and replay limits before it uses the identity for authorization?
