Traefik Forward Auth Keycloak
A traefik forward auth keycloak setup sends web requests to an external service for login checks. If the user passes the check, the router forwards the request to your internal app. Platform teams often use this setup to protect internal dashboards and admin tools. Still, broad group roles often give users full write rights once they pass the front door. A single valid cookie lets an engineer run any action inside the web app. How traefik forward auth keycloak works in practice Traefik sits a
Keycloak + Traefik Middleware Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A traefik forward auth keycloak setup sends web requests to an external service for login checks. If the user passes the check, the router forwards the request to your internal app. Platform teams often use this setup to protect internal dashboards and admin tools. Still, broad group roles often give users full write rights once they pass the front door. A single valid cookie lets an engineer run any action inside the web app.
How traefik forward auth keycloak works in practice
Traefik sits at the edge of your network and receives all incoming web traffic. It does not store user accounts or check passwords on its own. Instead, you set up a forward auth middleware rule on your chosen routes. When a user visits a protected route, the router pauses the request. It sends the request headers to a small helper service that talks to Keycloak.
This helper service checks if the user holds a valid session cookie or token. If the user is not logged in, the service redirects the browser to Keycloak. The user enters their password and completes a second factor check on that login page. Keycloak then issues a signed token and sends the browser back to the app route.
On the next request, the helper service reads the new token and verifies the signature. It can also check if the user belongs to a specific group or role. When the check passes, the helper returns a success status code to the edge router. It also attaches user identity headers, like the user email, to the approved request. Traefik then forwards the traffic and those identity headers straight to the backend app.
Where edge login checks fall short for internal apps
Setting up edge login rules solves a major problem for engineering teams. You do not need to build custom login pages for every internal tool. You can put one single sign-on wall in front of legacy dashboards and admin panels. If someone leaves the team, you disable their account in one central directory. They lose entry to all protected web routes right away.
Yet this edge check only decides who can open the front door. Once the router passes the request upstream, the edge check is done. The router does not inspect the body of the web request or API call. If an internal dashboard has a delete button, any logged-in user can click it. Unless the backend app reads identity headers and enforces fine rules, everyone gets full admin rights.
Keycloak + Traefik Middleware Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This creates a big risk for shared admin panels and internal APIs. An engineer might only need to read order status or check a queue. Because the edge check is binary, they also get the power to drop queues or edit records. Also, the edge router only logs basic web paths and status codes. It does not record which specific records changed or mask sensitive data in the response. If an API returns customer emails, phone numbers, or card numbers, the raw values appear on screen.
Managing role mapping and session timeouts
Teams often try to fix broad permissions by creating more groups in their directory. You can map different URL paths to different directory groups at the router level. For example, one group can view the main dashboard path while another group hits settings paths. This approach works for simple apps with clean URL structures. Still, most modern web apps send all actions through a single API path.
Session lifetime is another area that requires careful setup across both tools. Your directory issues tokens with a set expiration time, and the helper service caches sessions. If you set the cache time too long, revoked users keep working inside the app. Teams must align token lifetimes and cookie settings so logouts take effect right away.
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
Does Traefik talk directly to Keycloak out of the box?
Open-source Traefik needs a small forward auth helper service to speak the OpenID protocol with Keycloak. The router sends the check to the helper, and the helper handles the login redirect flow.
Can this setup restrict specific actions inside a web app?
Edge forward auth only approves or blocks access to routes based on login state and headers. Unless the upstream app parses identity headers to enforce its own rules, users get full app access.
How does the backend app know which user made the request?
After a user logs in, the auth service returns a success response with user details in headers. You configure the router to copy headers like user email and groups to the upstream app request.