Keycloak Reverse Proxy
You set up a keycloak reverse proxy by placing a web server before your identity service. This front server handles public web traffic and passes headers to the backend. Teams use this design to protect internal servers from direct public visits. Still, broad role mapping often gives users too much power after they log in. How a keycloak reverse proxy works A reverse proxy sits at the edge of your network. It takes every login request from a user browser first. The edge server handles TLS key
Keycloak + Reverse Proxy Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak reverse proxy by placing a web server before your identity service. This front server handles public web traffic and passes headers to the backend. Teams use this design to protect internal servers from direct public visits. Still, broad role mapping often gives users too much power after they log in.
How a keycloak reverse proxy works
A reverse proxy sits at the edge of your network. It takes every login request from a user browser first. The edge server handles TLS keys and stops bad network traffic early. Then it forwards clean requests to the identity server on a private network.
For this flow to work, headers must match the public domain. The edge server sets forwarded host, port, and protocol headers on each request. The identity server reads these headers to build the right redirect links. If the headers are missing, login redirects will point to internal private addresses.
Users will see broken pages when redirects point to private hostnames. You must tell the identity service to trust the edge server address. You also set the public hostname in the main server settings. This ensures tokens and cookies match the exact URL in the browser.
Managing client sessions and token routing
Once the network path works, teams connect their internal apps to the identity service. Each app trusts the public URL of the keycloak reverse proxy to check tokens. When a user visits an app, the app sends them to the login page. After the user signs in, they get a signed token for that app.
Admins often split admin pages and user login pages onto separate network paths. The edge server can block public access to the main admin console path. Only users on the office network can reach the admin settings page. Meanwhile, regular users can still reach the standard login endpoints from anywhere.
Load balancing is another key part of this setup for growing teams. One edge server can split traffic across several backend identity nodes. Those backend nodes share session states so users do not get logged out. If one backend node fails, the edge server sends traffic to healthy nodes.
Keycloak + Reverse Proxy Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and what it misses
A reverse proxy solves network exposure and TLS management very well. You keep your identity servers off the public internet at all times. You also manage all your public TLS certificates in one central place. It gives your team a single clean entry point for browser logins.
Still, this setup only checks who logs in at the start. It does not check what a user does inside a database or server later. Once an engineer gets a valid role, they often get full system permissions. The login server cannot read or block dangerous database queries or shell commands.
Shared roles also make auditing hard during a security review. You can see when someone logged in through the web page. Yet you cannot see the exact commands they ran on backend systems. Sensitive data like emails, phone numbers, and card numbers remains exposed 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 my login redirects fail behind an edge server?
Redirects fail when the backend server does not get the forwarded protocol headers. Make sure your edge server sends the host and protocol headers on every request.
Should the edge server handle TLS or pass it through?
Most teams end TLS at the edge server to make key updates simple. You can then use private TLS keys between the edge server and backend nodes.
How do I protect the admin console from public users?
Set a rule on your edge server to block the admin URL path. Allow requests to that path only from trusted office network addresses.