OAuth Login Issue with Multiple Pods

[vl-kp]

Issue submitter TODO list

• I've looked up my issue in FAQ
• I've searched for an already existing issues here
• I've tried running main-labeled docker image and the issue still persists there
• I'm running a supported version of the application which is listed here

Describe the bug (actual behavior)

Description

When running Kafka UI with multiple pods and OAuth authentication enabled, users experience login issues. The problem occurs because each pod maintains its own in-memory session store, causing session loss when requests are routed to different pods.

Current Behavior

• OAuth login works correctly with a single pod
• With multiple pods, users are logged out or need to re-authenticate when requests are routed to different pods
• This happens because each pod has its own in-memory session store

Expected behavior

• OAuth login should work consistently across multiple pods
• User sessions should be maintained regardless of which pod handles the request
• No re-authentication should be required when switching between pods

Your installation details

1.1.0

Steps to reproduce

• OAuth login works correctly with a single pod
• With multiple pods, users are logged out or need to re-authenticate when requests are routed to different pods

Screenshots

No response

Logs

No response

Additional context

The issue stems from the current session management implementation in the OAuth security configuration:

1. OAuth Security Configuration (in OAuthSecurityConfig.java):

@Configuration
@ConditionalOnProperty(value = "auth.type", havingValue = "OAUTH2")
@EnableConfigurationProperties(OAuthProperties.class)
@EnableWebFluxSecurity
@EnableReactiveMethodSecurity
public class OAuthSecurityConfig extends AbstractAuthSecurityConfig {
    @Bean
    public SecurityWebFilterChain configure(ServerHttpSecurity http, OAuthLogoutSuccessHandler logoutHandler) {
        var builder = http.authorizeExchange(spec -> spec
                .pathMatchers(AUTH_WHITELIST)
                .permitAll()
                .anyExchange()
                .authenticated()
            )
            .oauth2Login(Customizer.withDefaults())  // Uses default session handling
            .logout(spec -> spec.logoutSuccessHandler(logoutHandler))
            .csrf(ServerHttpSecurity.CsrfSpec::disable);
        // ... rest of configuration
    }
}

The issue here is that we're using Spring Security's default session handling without any distributed session configuration.

2. Session Management in OAuth Flow (in OAuthLogoutSuccessHandler.java):

@Component
@ConditionalOnProperty(value = "auth.type", havingValue = "OAUTH2")
public class OAuthLogoutSuccessHandler implements ServerLogoutSuccessHandler {
    @Override
    public Mono<Void> onLogoutSuccess(final WebFilterExchange exchange,
                                    final Authentication authentication) {
        // ... logout handling
        return exchange.getExchange().getSession().flatMap(WebSession::invalidate);
    }
}

The session invalidation is handled locally without considering distributed session management.

Technical Details

• The issue is related to Spring Security OAuth2's default session management
• Current implementation uses Spring's ReactiveSessionRepository with in-memory storage
• No configuration exists for distributed session management
• Affects Spring Security OAuth2's session handling in reactive applications

Proposed Solution

Implement Redis-based distributed session management as an optional feature:

1. Add Redis session support with proper configuration
2. Make Redis session management optional to maintain backward compatibility
3. Add proper documentation for Redis configuration

Configuration Example

spring:
  session:
    store-type: redis  # Optional, defaults to "none" for backward compatibility
    redis:
      host: your-redis-host
      port: 6379
      password: your-redis-password  # if required
    cookie:
      domain: your-domain  # for cookie sharing across pods

[github-actions]

Hi vl-kp! 👋

Welcome, and thank you for opening your first issue in the repo!

Please wait for triaging by our maintainers.

As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues.
Sponsorship link

If you plan to raise a PR for this issue, please take a look at our contributing guide.

[Haarolean]

Hi, thanks for a detailed report!

This is to be solved via sticky sessions in k8s, here's a detailed guide on this in our docs: link.
At the time being, we don't want to introduce any external dependencies like redis.
Let me know if that solves your issue.