Jwt X5c
The jwt x5c header stores a chain of public key certificates inside a token. Apps read this chain to check the token signature against a trusted root key. Teams often set up this header so services can check tokens without extra network calls. Still, a valid token often grants broad role access once the user logs in. If that role has wide permissions, the user can run risky commands without further checks. How the jwt x5c header works in practice A JSON Web Token has three main parts: a heade
X5c: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The jwt x5c header stores a chain of public key certificates inside a token. Apps read this chain to check the token signature against a trusted root key. Teams often set up this header so services can check tokens without extra network calls. Still, a valid token often grants broad role access once the user logs in. If that role has wide permissions, the user can run risky commands without further checks.
How the jwt x5c header works in practice
A JSON Web Token has three main parts: a header, a payload, and a signature. The jwt x5c field lives in the first part, which is the token header. It holds a list of public key certificates encoded as base64 text strings. The very first item in this list is the leaf certificate. This leaf item contains the exact public key needed to check the token signature. The next items in the list are intermediate certificates that link back to a root. When an app gets a token, it reads the header first. It decodes each item in the chain and checks the dates on them. Then the app checks that each certificate signed the one right before it. Finally, the app checks that the chain leads to a root key it already trusts. Only after the chain passes will the app use the leaf key on the token.
How to set up safe certificate chain checks
Setting up safe token checks requires strict rules in your app code. Never trust the leaf key in the header before you check the full chain. If an app skips the chain check, an attacker can send a fake key. The attacker signs a fake token with their own private key. Then they put their matching public certificate into the header and send the request. A careless app reads that fake certificate and accepts the bad token as real. To stop this attack, your app must pin a list of trusted root keys. You keep this trusted root list in local storage on your servers. Every incoming chain must link back to one of those local root keys. You also need a plan to check for revoked certificates on a regular schedule. Short expiration times on your tokens and leaf certificates help limit the risk of stolen keys.
What token checks solve and what they miss
Checking a token chain proves who sent the request and that the identity is real. It also lets services verify tokens fast without calling an outside key server every time. This setup solves the initial login step between users, apps, and backend services. Yet a valid token only decides who can enter the system at the start. It does not check what individual queries or commands the user runs after logging in. Once a service accepts the token, it maps the user to a broad role. A developer or service account with a valid token can still run a bad query. They might drop a table by mistake or pull a huge table of customer data. Token checks alone cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. Teams still need a way to inspect and control each command during an active session.
X5c: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between x5c and jku in a token header?
The x5c field puts the full certificate chain right inside the token header text. The jku field only gives a web link where the app must fetch the keys. Using x5c makes tokens larger, but the app does not need to make web requests.
Which certificate goes first in the x5c list?
The leaf certificate that holds the signing public key must always go first in the list. Each following certificate in the list must be the one that signed the previous certificate. The root certificate goes at the very end, or you can leave the root out.
Can an attacker put their own certificate in the x5c header?
Yes, anyone can build a token and put their own certificate chain inside the header. Your app stops this trick by checking that the chain leads to your own root key. If the chain does not end at a root you trust, your app rejects it.