Implement OIDC Front-Channel / Back-Channel Logout #5016

New Issue

OVERLORD · 2026-02-05T09:33:58+03:00

OVERLORD commented

2026-02-05 09:33:58 +03:00

Originally created by @timhallmann on GitHub (Oct 20, 2024).

Describe the feature you'd like

BookStack should provide endpoints for Front-Channel and Back-Channel Logout. This would enable the OpenID Provider to request the termination of a specific session or all sessions associated with a user.

Describe the benefits this would bring to existing BookStack users

Users do not need to log out of multiple applications
Users may log out from other devices than the one they used to log in
Administrators may initiate a logout

Can the goal of this request already be achieved via other means?

No.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

Not using yet, just scoping

Additional context

Requires #5278 (OIDC session handling).

Prior discussion in #3715 (RP-Initiated Logout).

The necessary specs have been finalized a while ago:

In terms of implementation, both Keycloak and Auth0 support Back-Channel Logout, although I've not looked into the extent of support from other OpenID Providers. Keycloak passes the OpenId Conformance tests for Front/Back-Channel Logout.

Plan to implement Front/Back-Channel Logout:

In routes / OidcController: Add an endpoint.
In OidcService: Validate and handle the request.
- There doesn't seem to be a method to query all sessions (independent of storage method), so what's the best way to execute a logout for an entirely different session? Add the session ID to a blacklist and perform the actual logout in the middleware?

Alternatively, implement custom sessions.

Notes / Considerations:

Front/Back-Channel Logout must be explicitly configured at the OP, so there's no need to make this configurable in BookStack.
In order to receive logout requests, we need to keep the clients session at the OP alive, meaning we have to implement the session management described in #5278.

Originally created by @timhallmann on GitHub (Oct 20, 2024). ### Describe the feature you'd like BookStack should provide endpoints for Front-Channel and Back-Channel Logout. This would enable the OpenID Provider to request the termination of a specific session or all sessions associated with a user. ### Describe the benefits this would bring to existing BookStack users - Users do not need to log out of multiple applications - Users may log out from other devices than the one they used to log in - Administrators may initiate a logout ### Can the goal of this request already be achieved via other means? No. ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundamental request ### How long have you been using BookStack? Not using yet, just scoping ### Additional context Requires #5278 (OIDC session handling). Prior discussion in #3715 (RP-Initiated Logout). The necessary specs have been finalized a while ago: - https://openid.net/specs/openid-connect-frontchannel-1_0.html - https://openid.net/specs/openid-connect-backchannel-1_0.html In terms of implementation, both Keycloak and Auth0 support Back-Channel Logout, although I've not looked into the extent of support from other OpenID Providers. Keycloak passes the OpenId Conformance tests for Front/Back-Channel Logout. Plan to implement Front/Back-Channel Logout: - In routes / OidcController: Add an endpoint. - In OidcService: Validate and handle the request. - There doesn't seem to be a method to query all sessions (independent of storage method), so what's the best way to execute a logout for an entirely different session? Add the session ID to a blacklist and perform the actual logout in the middleware? Alternatively, implement custom sessions. Notes / Considerations: - Front/Back-Channel Logout must be explicitly configured at the OP, so there's no need to make this configurable in BookStack. - In order to receive logout requests, we need to keep the clients session at the OP alive, meaning we have to implement the session management described in #5278.

OVERLORD added the 🔨 Feature Request label 2026-02-05 09:33:58 +03:00

OVERLORD closed this issue

2026-02-05 09:33:59 +03:00

OVERLORD commented

2026-02-05 09:34:01 +03:00

@IntelligentesTierMaulApollo13 commented on GitHub (Jan 2, 2025):

@timhallmann In the meantime it is maybe an option to use the SAML2 interface. As I discovered recently (unfortunately only after having changed my installation from LDAP to OIDC already) the SAML2 implementation seems to support both RP-initiated as well as IdP-initiated SLO (I just don't know about session handling especially with multiple devices).

@IntelligentesTierMaulApollo13 commented on GitHub (Jan 2, 2025): @timhallmann In the meantime it is maybe an option to use the SAML2 interface. As I discovered recently (unfortunately only after having changed my installation from LDAP to OIDC already) the SAML2 implementation seems to support both RP-initiated as well as IdP-initiated SLO (I just don't know about session handling especially with multiple devices).

OVERLORD commented

2026-02-05 09:34:04 +03:00

@timhallmann commented on GitHub (Jan 9, 2025):

As far as I understand the SAML implementation, or rather the authentication implementation in general, Back-Channel Logout is currently not possible at all, as we can't access the server-side sessions of other users. Front-Channel Logout on its own offers little benefit in our case, at least not enough to use SAML instead.

However, Front-Channel Logout could be added to OIDC with probably little effort as well, as it would not need changes to the session management. If it's helpful to others, it could be tracked independently through a new issue.

@timhallmann commented on GitHub (Jan 9, 2025): As far as I understand the SAML implementation, or rather the authentication implementation in general, Back-Channel Logout is currently not possible at all, as we can't access the server-side sessions of other users. Front-Channel Logout on its own offers little benefit in our case, at least not enough to use SAML instead. However, Front-Channel Logout could be added to OIDC with probably little effort as well, as it would not need changes to the session management. If it's helpful to others, it could be tracked independently through a new issue.

OVERLORD commented

2026-02-05 09:34:06 +03:00

@schlupmann commented on GitHub (Mar 27, 2025):

Back-Channel logout works for us with simplesamlphp (see comment https://github.com/BookStackApp/BookStack/issues/2715#issuecomment-2751572787)
I haven't looked into OIDC, but as simplesamlphp does support various other protocols, OIDC included, it should be possible to make the SOAP logout work with OIDC.

@schlupmann commented on GitHub (Mar 27, 2025): Back-Channel logout works for us with simplesamlphp (see comment https://github.com/BookStackApp/BookStack/issues/2715#issuecomment-2751572787) I haven't looked into OIDC, but as simplesamlphp does support various other protocols, OIDC included, it should be possible to make the SOAP logout work with OIDC.

OVERLORD commented

2026-02-05 09:34:08 +03:00

@timhallmann commented on GitHub (Mar 31, 2025):

@schlupmann Thank you for publishing (and explaining!) your code, I really appreciate it. It made me realize I've been severely overthinking even a hackish implementation of Back-Channel Logouts (and sessions). Though, knowing neither Laravel nor PHP didn't help.

Following your example, I've implemented Backchannel Logout by accessing the database session directly. Having done that, I noticed I could easily implement session management as well. So easily in fact, I wish I hadn't bothered with Backchannel Logout at all.

The code can be found in this gist.

It seems to work fine, except when multiple refreshes are triggered via concurrent requests. I'm not sure how to best lock that section, but users are unlikely to encounter this issue -- I certainly didn't, even while trying to test for it.

Since this solution works for our use case, I'm closing this issue.

@timhallmann commented on GitHub (Mar 31, 2025): @schlupmann Thank you for [publishing](https://github.com/BookStackApp/BookStack/issues/2715#issuecomment-2761432386) (and explaining!) your code, I really appreciate it. It made me realize I've been severely overthinking even a hackish implementation of Back-Channel Logouts (and sessions). Though, knowing neither Laravel nor PHP didn't help. Following your example, I've implemented Backchannel Logout by accessing the database session directly. Having done that, I noticed I could easily implement session management as well. So easily in fact, I wish I hadn't bothered with Backchannel Logout at all. The code can be found in this [gist](https://gist.github.com/timhallmann/464fad847c6e9e4a401f847639095faf). It seems to work fine, except when multiple refreshes are triggered via concurrent requests. I'm not sure how to best lock that section, but users are unlikely to encounter this issue -- I certainly didn't, even while trying to test for it. Since this solution works for our use case, I'm closing this issue.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5016