Keycloak Behind Proxy
To run keycloak behind proxy servers, you must pass client network headers to the identity server. You also need to match the public host name in your server settings. Teams often place a load balancer in front of the login server to manage TLS certificates. This setup keeps the identity server off the public internet. Still, broad login roles still give users too much power once they reach internal systems. How to set up keycloak behind proxy A reverse proxy sits between your users and the i
Keycloak + Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run keycloak behind proxy servers, you must pass client network headers to the identity server. You also need to match the public host name in your server settings. Teams often place a load balancer in front of the login server to manage TLS certificates. This setup keeps the identity server off the public internet. Still, broad login roles still give users too much power once they reach internal systems.
How to set up keycloak behind proxy
A reverse proxy sits between your users and the internal login server. The outer server takes incoming web traffic and reads the public domain name. It handles TLS encryption at the network edge and sends traffic to the internal node. The login server must know the original client address and protocol to build valid redirect links. If the server does not see these headers, login redirects will fail with protocol errors.
You fix this by telling the login server to trust forwarded network headers from the edge. The outer router attaches the client IP address, host name, and web protocol to each request. The identity server reads those headers and writes matching login tokens and cookie paths. You must also lock down the internal network so traffic only comes from the edge router. If any other host can send fake headers, an attacker could spoof client network addresses.
How header forwarding and admin paths work
Most teams split public login traffic from internal admin traffic at the network edge. Public users only need to reach the token, login, and user account paths. The admin console should stay hidden behind a private network rule on the router. This prevents outside attackers from guessing admin passwords on the public web interface.
You also need to match session timeouts between the edge router and the identity server. If the router closes idle network links too fast, long login flows may drop mid-request. Keep health check paths simple so the load balancer knows when nodes are ready. When a node fails a check, the router stops sending login requests to that server. Sticky sessions are rarely needed if your cluster shares user login state across nodes.
Keycloak + Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login servers solve and the gap they leave open
Placing your login server behind an edge router solves public network routing and certificate management. It gives your team one place to manage user accounts, groups, and multi-factor rules. When a developer logs in, the identity server checks their identity and assigns a role. This works well for web apps that trust standard identity tokens.
Still, an identity server only decides who logs in at the start of a session. It cannot inspect or limit what individual database statements or shell commands do in flight. Once an engineer uses that role to reach a database, the login server steps aside. A user with read rights can still pull thousands of customer emails and card numbers. Login tokens also do not stop a developer from running a bad update query in production. To protect live data, teams must control queries and commands at the runtime level. Masking rules can then rewrite emails, phone numbers, and national IDs in query results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do login redirects fail with mixed content errors?
The identity server thinks requests use plain HTTP because the edge router stripped TLS first. You must configure the router to send the forwarded protocol header and tell the server to trust it.
Should I expose the admin console through the public load balancer?
No, you should block public access to admin paths at the outer router level. Let admins reach the management console only through a private network path.
Does single sign-on control what queries a user runs in a database?
No, single sign-on only checks who the user is when they first log in. It does not inspect live SQL queries, block dangerous commands, or mask card numbers in results.