Haproxy Jwt
You set up an haproxy jwt check by reading request headers at your load balancer. The load balancer checks the token signature against a public key before routing traffic. Most teams use this setup to block bad requests at the network edge. Still, broad token scopes often give users too much power inside backend apps. Once a token passes the edge check, the user can run any backend command. How the native haproxy jwt workflow operates A client logs in to an identity provider and gets a signed
HAProxy Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an haproxy jwt check by reading request headers at your load balancer. The load balancer checks the token signature against a public key before routing traffic. Most teams use this setup to block bad requests at the network edge. Still, broad token scopes often give users too much power inside backend apps. Once a token passes the edge check, the user can run any backend command.
How the native haproxy jwt workflow operates
A client logs in to an identity provider and gets a signed token. The client sends this token in the header of every web request. Your load balancer catches the request before it reaches your core backend apps. It splits the token into three parts: the header, the payload, and the signature.
First, the load balancer checks the algorithm listed in the token header. You must lock this rule down so attackers cannot swap the signing method. Next, the load balancer uses your local public key to check the signature. This step proves that your trusted identity provider made the token.
Then, the load balancer reads the claims inside the token payload. It checks the issuer name and the target audience for the app. It also reads the expiration time to make sure the token is still active. If any check fails, the load balancer drops the request right away. If all checks pass, the load balancer sends the request to the backend server.
What edge token checks solve and what they miss
Checking tokens at the load balancer saves work for your backend apps. Your app servers do not need to waste CPU cycles on bad traffic. You also keep your public keys in one place instead of many apps. This setup works well for basic entry control at the network edge.
Yet this edge check only decides who can enter the network. It does not control what happens inside the session after the check passes. A valid token might grant a broad role to a developer or service. That role lets the user run any query or read any table.
Edge load balancers do not read database queries or system commands in flight. They cannot mask sensitive data like emails, phone numbers, or card numbers in responses. If an attacker steals a valid token, they bypass the edge check with ease. Also, you cannot kill a valid token at the edge until it expires. You must either wait for the timer or rotate the whole signing key.
HAProxy Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing public keys and token claims
To keep your setup safe, you must manage your public keys with care. Identity providers rotate their signing keys on a set schedule to stay safe. Your load balancer needs the new public key before the old one dies. Many teams use a background script to fetch fresh keys and reload the service.
You should also pass specific token claims to your backend apps as headers. The load balancer can read the user ID or group role from the payload. It then writes those values into fresh request headers for the backend app. Make sure the load balancer strips out any old headers from the client first. This stops users from faking their role by sending custom headers from outside.
Even with clean headers, your backend team still carries a heavy burden. Every single app must read those headers and enforce its own data rules. When you have dozens of backend tools, rules get out of sync fast. Teams need a way to inspect actual commands and protect data in flight.
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
Can the load balancer fetch public keys on every request?
No, the load balancer reads public keys from local memory to stay fast. You must update local key files with a helper script when keys rotate.
What happens if a user token is stolen before it expires?
The load balancer will keep accepting the stolen token until the expiration time hits. You must set short token lifetimes or maintain a local blocklist to stop it.
Does a token check hide sensitive fields in backend responses?
No, an edge token check only approves or blocks the initial web request. It does not inspect payloads or rewrite emails and card numbers in results.