Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for removing OIDC user session with Spring Session in OIDC backchannel logout #16629

Open
aelillie opened this issue Feb 21, 2025 · 0 comments
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement

Comments

@aelillie
Copy link

Implementing OIDC backchannel logout with Spring Security 6.4.2 in a clustered Spring JDBC Session context, I need a way to remove the OIDC user session saved by the OidcSessionRegistry, when the OidcBackChannelLogoutHandler performs a POST request for logging out the user. The issue is not with the registry, as I've implemented storing of the OIDC user sessions with JDBC. The issue is to automatically call the OidcSessionRegistry#removeSessionInformation when the Spring Session gets invalidated.

As mentioned in https://docs.spring.io/spring-security/reference/servlet/oauth2/login/logout.html#configure-provider-initiated-oidc-logout "you need a way listen to events published by Spring Security to remove old OidcSessionInformation entries [..]" by declaring a HttpSessionEventPublisher as a Bean. This works fine in a none-Spring Session context, but when using Spring Session, to support a clustered setup, the event is not picked up, and the OIDC user session is thus not removed.

As such, this is a request to add support in Spring Security to remove the OIDC user session from the OidcSessionRegistry when a session is invalidated in a Spring Session context.

To reproduce

  1. Prepare an application which uses Spring Session stored in JDBC + OIDC backchannel logout configured
  2. Log in to the application using OIDC integration
  3. Trigger OIDC back channel logout

Expected Behavior

  1. The OIDC user session in the OidcSessionRegistry is removed when the Spring Session is invalidated.

Current Behavior

  1. The Spring Session gets invalidated, but the OIDC user session remains in the OidcSessionRegistry.

Context

Using Spring Boot 3.4.2, Spring Session (JDBC) 3.4.1, and Spring Security 6.4.2.

My current workaround is to define a LogoutHandler, which makes sure to remove the OIDC user session from the registry, if a valid session is present. Minimal example:

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http, OidcSessionLogoutHandler oidcSessionLogoutHandler, ...) {
        return http
                ...
                .logout(logout -> logout
                        .addLogoutHandler(oidcSessionLogoutHandler)
                        ...
                )
               ...
                .build();
    }
@Slf4j
@Component
public class OidcSessionLogoutHandler implements LogoutHandler {
    private final OidcSessionRegistry oidcSessionRegistry;

    public OidcSessionLogoutHandler(OidcSessionRegistry oidcSessionRegistry) {
        this.oidcSessionRegistry = oidcSessionRegistry;
    }

    @Override
    public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {
        var session = request.getSession(false);
        if (session == null) {
            log.debug("No valid session found. Ignoring OIDC Session logout.");
            return;
        }
        var removedSession = oidcSessionRegistry.removeSessionInformation(session.getId());
        if (removedSession == null) {
            log.trace("No OIDC session found for id {}. Could be caused by an OIDC Back Channel Logout, " +
                    "where the session info is already removed", session.getId());
        } else {
            log.trace("Removed OIDC session with id {}", removedSession.getSessionId());
        }
    }
}
@aelillie aelillie added status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant