Guidance Needed: Keycloak Single Logout Implementation

[atul tiwari]

Hi Team,

I have two projects running — one in Remix and one in Superset. I’m using Keycloak for authentication, and in both projects I manage sessions through browser cookies. Once a user logs in to my app via Keycloak, I create a session and store it in the browser for further request authorization. SSO login across both apps is working fine.

The challenge I’m facing is with logout. I want to achieve single logout so that logging out from one app logs the user out from all other applications in real time. I’ve explored both front-channel and back-channel logout, but haven’t found a concrete solution yet.

Below are my observations so far:

1. API Session Validation

   • Implement session validation by calling the Keycloak API on every request.

   • Limitation: This would add multiple API calls to the server, impacting performance.

2. Redis-based Session Management

   • Store session data in Redis instead of browser cookies. Each request can then be validated against Redis.

   • Limitation: If Redis becomes unavailable, the login flow will be completely blocked.

3. Front-Channel Logout

   • Keycloak uses iframes to trigger logout URLs for each client.

   • Limitation: Fragile due to iframe-related issues (third-party cookie blocking, CSP, X-Frame-Options, browser privacy restrictions).

4. Back-Channel Logout

   • Works via server-to-server logout notifications.

   • Limitation: This is not effective in my current setup since sessions are stored only in browser cookies, and the server has no visibility into them.

I’d like to know what would be the recommended approach to manage sessions and implement a robust single logout flow in this scenario. Any best practices or industry-standard approaches would be very helpful.

Thanks,
Atul

[Björn Pedersen]

atul tiwari schrieb am Donnerstag, 9. Oktober 2025 um 11:12:13 UTC+2:

Hi Team,

I have two projects running — one in Remix and one in Superset. I’m using Keycloak for authentication, and in both projects I manage sessions through browser cookies. Once a user logs in to my app via Keycloak, I create a session and store it in the browser for further request authorization. SSO login across both apps is working fine.

The challenge I’m facing is with logout. I want to achieve single logout so that logging out from one app logs the user out from all other applications in real time. I’ve explored both front-channel and back-channel logout, but haven’t found a concrete solution yet.

Below are my observations so far:

1. API Session Validation

   • Implement session validation by calling the Keycloak API on every request.

   • Limitation: This would add multiple API calls to the server, impacting performance.

This is one typical approach used.

 

2. Redis-based Session Management

   • Store session data in Redis instead of browser cookies. Each request can then be validated against Redis.

   • Limitation: If Redis becomes unavailable, the login flow will be completely blocked.

3. Front-Channel Logout

   • Keycloak uses iframes to trigger logout URLs for each client.

   • Limitation: Fragile due to iframe-related issues (third-party cookie blocking, CSP, X-Frame-Options, browser privacy restrictions).

4. Back-Channel Logout

   • Works via server-to-server logout notifications.

   • Limitation: This is not effective in my current setup since sessions are stored only in browser cookies, and the server has no visibility into them.

Your backends need some session reference internally as well( most applications only store a session id in the cookie, and a reference to that id in a  db, in a  filesystem or e.g. redis). The logout invalidates/deletes the serverside part.

[atul tiwari]

Hi Team,

Thank you for your response. Currently, I manage sessions using browser cookies only. I’m new to server-side session management and am considering moving to using Redis as a session store. I have a few questions and would really appreciate your guidance:

1. How do organizations handle logins if the Redis server is unavailable? Are there recommended fallback strategies?

2. Is storing session data on the server side a good approach in terms of scalability, reliability, and security?

3. Are there best practices for session persistence and handling high traffic when using Redis for session management?

Thank you in advance for your help!

Best regards,
Atul

[Kris Hardy]

I'd recommend reading this in depth if you haven't already: 

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

In your example, Redis is a critical service if it is being used for session data. The only safe thing to do is not allow authentication if Redis is down. I'm not aware of any common fail over patterns to point you towards. 

If you use a backend log out, you could still store the session data in the browser. Your application backend can maintain a record that would have a session id and user id. On each request, validate that the record hasn't expired or been logged out. When the backend log out occurs, mark the record as logged out. On the next request, you can then trigger the session deletion in the browser.

If you use a browser-based logout without iframes, you can chain redirects together to cause the logout at one app to then redirect to the logout at the other app. Or you could have the logout page open multiple tabs to trigger logout in parallel. If I was to go this way, I'd have a logout service that the browser goes to which would start the logout, and each application would handle their logout, the redirect back to the logout service.

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/1e0bfd9f-4c46-420e-8b5a-39cd2268af2dn%40googlegroups.com.