Hi,
When I try to use the “Sign out all sessions” on a sessions page in Keycloak it appears the back-channel endpoint is not being called.
If I individually sign each session out in the UI, Keycloak trigger backchannel logout to my server and the user is logged out.
Is this by design? Can anyone confirm on this?
Keycloak version - 22.0.5
I second that question, seems like a bug to me
If this is still a problem, I am suggesting to check what Keycloak event is published to ‘events’ section and to create custom Event Listener, then programatically do logout from you system through REST call or even in Keycloak using KeycloakSession…
I am encountering the same issue with a vanilla Keycloak 26.0.5 when I use the realm’s admin console → Sessions to sign out a user.
I am fairly sure it is not a OP → RP connectivity issue.
I would love to be able to confirm if KC is actually invoking the RP backchannel logout endpoint.
But relatively new to KC and would appreciate any guidance on how to view logs (e.g. do I need a special JOBSS viewer or do I access the logs by logging onto a sheel in the KC container?)
Thanks so much in advance!
AFAIK this is not a bug but intended.
When a user logs out or a session is invalidated by an admin, and there are client session from a client with a configured backchannel logout url, Keycloak will send an logout token to these clients for this respective user.
So far, so good for a single user session.
When you invalidate all sessions of all users (logout all users), then this might yield possibly in a huge number of requests Keycloak would have to send and would block/limit the available resources, in Keycloak as in the clients.
A simple calculation:
You have 500.000 user sessions, each user as an average of 3 client sessions from clients with backchannel logout, Then, Keycloak would have to send 1.500.000 logout requests to these clients.
Even if it would be possible to send 5000 requests each second, this task would last 5 minutes at least.
Additionally, all the clients would have to handle this amount of logout requests.
Thank you so much for your response! I would really appreciate some additional clarifications.
In the scenario that an administrator signs out a user and Keycloak does not invoke the RP’s backchannel logout, is the design decision here that it is ok for the user to keep accessing the RP until a subsequent access token refresh fails? But does that decision not leave open RP access for the user in the period that the access token is valid which seems to be a security concern?
Also if Keycloak does not invoke the backchannel logout, is the latest Server Administration guide, Section 10 SSO Protocols > Open ID Connect > OIDC Logout > RP-initiated Logout, inconsistent with the design?
(Re: the first point, perhaps the design decision is motivated by the assumption that the RP will support additional session state management? Which could very well be motivated by some valid security scenarios - I am not fully conversant with the various security scenarios.)
Yes, but… This “gap” is a known gap and is accepted since the start of OIDC. The logout specs are additional specs which came later. Additionally, these are not mandatory.
To mitigate this gap, it’s recommended to set the lifetime of the access token as short as possible/meaningful.
I’d say no.
IMHO the spec is about a logout of a single user, which is redirected in the browser from a client (RP) to the IdP to perform the logout. Not about invalidating all sessions directly on the IdP by an admin.
Many thanks for your reply!
I am seeing this behavior for a single user also. But I will debug further to confirm.
That said, perhaps adding such clarification as you provided to the documentation may be helpful for others in future? Happy to help in any way I can.
For invalidating single user sessions in the admin-ui I don’t see any errors, this behaves similar to a PR-initiated logout. Keycloak is sending the logout tokens properly to the client(s). At least in my environment(s).
