Spring Security Session Management: Concurrency, Timeout & Fixation

Session management is one of those Spring Security features that seems straightforward until it bites you in production. I've seen countless applications where users could log in from multiple browsers without restriction, sessions never expired, or worst of all, session fixation attacks were wide open because developers assumed Spring Boot's defaults were enough.

Here's the hard truth: most teams get session management wrong. They configure maximumSessions(1) and think they're done, only to discover that the second login doesn't kick the first one out. Or they set a session timeout in application.properties and wonder why it's ignored. Or they don't realize that session fixation protection is enabled by default but can be accidentally disabled with a misconfiguration.

In this article, I'll walk you through the three pillars of session management in Spring Security: concurrency control (how many sessions per user), timeout (when sessions die), and fixation protection (preventing session theft). I'll include real code examples, production war stories, and the gotchas that the official docs gloss over. By the end, you'll know exactly how to configure sessions for a secure, production-ready application.

We'll use Spring Boot 3.2 and Spring Security 6.2. The principles apply to earlier versions, but the exact configuration may differ slightly.

Setting Up Session Management in Spring Security

Let's start with the basics. Session management in Spring Security is configured via the HttpSecurity object. The key method is sessionManagement(), which allows you to define session creation policy, concurrency control, and fixation protection.

Here's a minimal configuration for a stateless application (like a REST API using JWT):

```java @Configuration @EnableWebSecurity public class SecurityConfig {

@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.STATELESS) ); return http.build(); } } ```

But for stateful applications (traditional server-side sessions), you'll want something like this:

```java @Configuration @EnableWebSecurity public class SecurityConfig {

@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) .maximumSessions(1) .maxSessionsPreventsLogin(false) .sessionRegistry(sessionRegistry()) ) .sessionFixation(sessionFixation -> sessionFixation .migrateSession() ); return http.build(); }

@Bean public SessionRegistry sessionRegistry() { return new SessionRegistryImpl(); }

@Bean public HttpSessionEventPublisher httpSessionEventPublisher() { return new HttpSessionEventPublisher(); } } ```

Notice the SessionRegistry and HttpSessionEventPublisher beans. These are critical for concurrency control to work. The SessionRegistry tracks active sessions, and HttpSessionEventPublisher listens for session destruction events to keep the registry clean.

Key Takeaway: Always define SessionRegistry and HttpSessionEventPublisher beans when using concurrent session control. Without them, maximumSessions(1) is essentially a no-op.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
                .maximumSessions(1)
                .maxSessionsPreventsLogin(false)
                .sessionRegistry(sessionRegistry())
            )
            .sessionFixation(sessionFixation -> sessionFixation
                .migrateSession()
            );
        return http.build();
    }

    @Bean
    public SessionRegistry sessionRegistry() {
        return new SessionRegistryImpl();
    }

    @Bean
    public HttpSessionEventPublisher httpSessionEventPublisher() {
        return new HttpSessionEventPublisher();
    }
}

Concurrency Control: Limiting User Sessions

Concurrency control is about limiting how many active sessions a single user can have. This is critical for security (preventing account sharing) and resource management.

Spring Security provides two strategies when a user exceeds the maximum: 1. maxSessionsPreventsLogin(false) (default): The oldest session is expired, and the new login succeeds. 2. maxSessionsPreventsLogin(true): The new login is rejected with an error.

Most applications prefer the first approach (kick out the old session). But beware: this relies on the SessionRegistry to track sessions. If the registry is not properly configured, the old session won't be expired.

Here's how to implement custom logic when a session is expired:

``java http .sessionManagement(session -> session .maximumSessions(1) .maxSessionsPreventsLogin(false) .expiredSessionStrategy(new SessionInformationExpiredStrategy() { @Override public void onExpiredSessionDetected(SessionInformationExpiredEvent event) throws IOException, ServletException { HttpServletResponse response = event.getResponse(); response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write("Session expired due to concurrent login"); } }) .sessionRegistry(sessionRegistry()) ); ``

Production Insight: The SessionInformationExpiredStrategy is invoked when a request comes in with an expired session ID. This happens asynchronously; the old session is marked expired in the registry, but the user's browser still has the old cookie. The strategy handles the next request from that browser.

What the docs don't tell you: If you're using a distributed session store (like Redis with Spring Session), the SessionRegistry must be shared across all instances. Otherwise, each instance has its own view of sessions, and concurrency control breaks. Use a RedisIndexedSessionRepository with a custom SessionRegistry that queries the shared store.

http
    .sessionManagement(session -> session
        .maximumSessions(1)
        .maxSessionsPreventsLogin(false)
        .expiredSessionStrategy(event -> {
            HttpServletResponse response = event.getResponse();
            response.setStatus(HttpStatus.UNAUTHORIZED.value());
            response.getWriter().write("Session expired due to concurrent login");
        })
        .sessionRegistry(sessionRegistry())
    );

Session Timeout: When Sessions Die

Session timeout determines how long a session can remain idle before it's invalidated. In Spring Boot, you can set the timeout in application.properties:

``properties server.servlet.session.timeout=30m ``

This sets the idle timeout to 30 minutes. The value must be a duration (e.g., 30m, 1h, 15m). If you set it to -1, the session never times out (not recommended).

But there's a catch: if you're using Spring Security's sessionManagement() with maximumSessions(), the timeout can be overridden by the SessionRegistry. The registry tracks sessions and their last request time. When a session is checked for expiration, the registry compares the last request time with the configured timeout.

You can also programmatically set the timeout on the HttpSession:

``java httpSession.setMaxInactiveInterval(1800); // 30 minutes in seconds ``

Production Insight: The server.servlet.session.timeout property only applies to the servlet container's session timeout. If you have a custom SessionRegistry that doesn't respect this, sessions may not expire as expected. Always test timeout behavior with an integration test.

What the official docs won't tell you: In Spring Boot 3.2, if you set server.servlet.session.timeout and also use sessionManagement().maximumSessions(), the timeout is enforced by the SessionRegistry only if the registry's getAllSessions() method returns sessions with correct last request times. If you forget to update the last request time (e.g., by not calling SessionRegistry.refreshLastRequest()), sessions may expire prematurely or not at all.

server.servlet.session.timeout=30m

Session Fixation Protection: Preventing Session Theft

Session fixation is an attack where an attacker forces a user to use a session ID known to the attacker. After the user logs in, the attacker can hijack the session if the session ID doesn't change.

Spring Security provides three strategies: 1. migrateSession() (default): Creates a new session and copies attributes from the old one. The old session is invalidated. 2. newSession(): Creates a new session without copying attributes. 3. none(): No protection (never use this in production).

Configuration is straightforward:

``java http .sessionFixation(sessionFixation -> sessionFixation .migrateSession() ); ``

Production Insight: The default is migrateSession(), which is secure for most applications. However, if you have custom session attributes that should not be carried over (e.g., unauthenticated state), use newSession() instead.

What the official docs won't tell you: Session fixation protection only works if the session is created before authentication. If you're using a stateless authentication mechanism (like JWT), session fixation is not relevant because there is no server-side session. But if you mix stateful and stateless (e.g., session for some endpoints, JWT for others), ensure fixation protection is applied to the stateful paths.

Another gotcha: if you have a custom SessionAuthenticationStrategy, it can override the fixation protection. For example:

``java http .sessionManagement(session -> session .sessionAuthenticationStrategy(customStrategy) ); ``

If customStrategy doesn't call ChangeSessionIdAuthenticationStrategy, fixation protection is lost. Always chain your custom strategy with the default one.

Debugging Tip: To verify fixation protection is working, inspect the JSESSIONID cookie before and after login. If it changes, protection is active. Use browser developer tools or a tool like curl with --cookie-jar.

http
    .sessionFixation(sessionFixation -> sessionFixation
        .migrateSession()
    );

What the Official Docs Won't Tell You

After years of debugging session management issues, here are the gotchas that the Spring Security reference documentation glosses over:

1. SessionRegistry is not auto-configured. The docs show examples with sessionRegistry() bean, but they don't emphasize that without it, maximumSessions() is a no-op. I've seen this in at least five production codebases.
2. HttpSessionEventPublisher is required for cleanup. If you don't register this bean, when a session expires or is destroyed, the SessionRegistry still holds a reference to it. This leads to memory leaks and incorrect concurrency enforcement.
3. maxSessionsPreventsLogin(false) doesn't immediately expire the old session. It marks the old session as expired in the registry, but the old session's cookie is still valid until the next request from that browser. The SessionInformationExpiredStrategy only fires when the old session tries to make a request.
4. Distributed sessions break concurrency control. If you use Spring Session with Redis, the default SessionRegistry is local. You need a shared registry. The docs mention FindByIndexNameSessionRepository but don't provide a ready-to-use SessionRegistry implementation for Redis.
5. server.servlet.session.timeout is not respected by SessionRegistry. The servlet container enforces timeout at the container level, but the SessionRegistry has its own expiration logic based on last request time. If the registry's last request time is not updated, sessions may expire prematurely.
6. Custom SessionAuthenticationStrategy can break fixation protection. If you inject a custom strategy, ensure it delegates to ChangeSessionIdAuthenticationStrategy. Otherwise, the session ID won't change on authentication.
7. Session fixation protection is irrelevant for stateless apps. If you're using JWT, you don't need to worry about session fixation. But many developers configure it anyway, adding unnecessary complexity.

Production Proven Solution: For a robust setup, use the following checklist: - Define SessionRegistry bean. - Register HttpSessionEventPublisher. - Configure sessionManagement() with maximumSessions(1) and sessionRegistry(). - Use migrateSession() for fixation protection. - For distributed sessions, implement a shared SessionRegistry using Redis or database. - Test concurrency with integration tests that simulate multiple logins.

@Configuration
@EnableWebSecurity
public class RobustSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
                .maximumSessions(1)
                .maxSessionsPreventsLogin(false)
                .sessionRegistry(sessionRegistry())
            )
            .sessionFixation(sessionFixation -> sessionFixation
                .migrateSession()
            );
        return http.build();
    }

    @Bean
    public SessionRegistry sessionRegistry() {
        return new SessionRegistryImpl();
    }

    @Bean
    public HttpSessionEventPublisher httpSessionEventPublisher() {
        return new HttpSessionEventPublisher();
    }
}

Advanced: Custom Session Registry for Distributed Environments

In a microservices architecture with multiple instances, the default SessionRegistryImpl is inadequate because it stores sessions in local memory. Each instance has its own registry, so a user can log in from instance A and then from instance B, and both sessions are allowed because the registries don't communicate.

To solve this, you need a shared SessionRegistry backed by Redis, database, or another distributed store. Spring Session provides FindByIndexNameSessionRepository which can be used to query sessions by principal name. However, it doesn't implement SessionRegistry directly.

Here's a custom SessionRegistry that uses Redis via FindByIndexNameSessionRepository:

```java @Component public class RedisSessionRegistry implements SessionRegistry {

private final FindByIndexNameSessionRepository<? extends Session> sessionRepository;

public RedisSessionRegistry(FindByIndexNameSessionRepository<? extends Session> sessionRepository) { this.sessionRepository = sessionRepository; }

@Override public List<Object> getAllPrincipals() { // Not straightforward; requires scanning all sessions. Consider using a separate index. throw new UnsupportedOperationException("Not implemented"); }

@Override public List<SessionInformation> getAllSessions(Object principal, boolean includeExpiredSessions) { String principalName = (principal instanceof UserDetails) ? ((UserDetails) principal).getUsername() : principal.toString(); return sessionRepository.findByPrincipalName(principalName) .stream() .map(session -> new SessionInformation(session.getPrincipal(), session.getId(), session.getLastAccessedTime())) .filter(info -> includeExpiredSessions || !info.isExpired()) .collect(Collectors.toList()); }

@Override public SessionInformation getSessionInformation(String sessionId) { Session session = sessionRepository.findById(sessionId); if (session == null) return null; return new SessionInformation(session.getPrincipal(), session.getId(), session.getLastAccessedTime()); }

@Override public void refreshLastRequest(String sessionId) { sessionRepository.findById(sessionId).ifPresent(session -> { session.setLastAccessedTime(Instant.now()); sessionRepository.save(session); }); }

@Override public void registerNewSession(String sessionId, Object principal) { // Spring Session handles creation automatically; no need to register explicitly. }

@Override public void removeSessionInformation(String sessionId) { sessionRepository.deleteById(sessionId); } } ```

Production Insight: The getAllPrincipals() method is hard to implement efficiently with Redis because it requires scanning all keys. If you need this functionality, consider maintaining a separate index (e.g., a set of principal names in Redis).

What the official docs won't tell you: Spring Session's FindByIndexNameSessionRepository uses a secondary index to find sessions by principal name. This index is updated automatically when you save a session with the principal name set. However, if you use SessionRegistry.registerNewSession(), you must ensure the principal name is set on the session. The default SessionRegistryImpl does this, but custom implementations must handle it.

@Component
public class RedisSessionRegistry implements SessionRegistry {

    private final FindByIndexNameSessionRepository<? extends Session> sessionRepository;

    public RedisSessionRegistry(FindByIndexNameSessionRepository<? extends Session> sessionRepository) {
        this.sessionRepository = sessionRepository;
    }

    @Override
    public List<Object> getAllPrincipals() {
        throw new UnsupportedOperationException("Not implemented");
    }

    @Override
    public List<SessionInformation> getAllSessions(Object principal, boolean includeExpiredSessions) {
        String principalName = (principal instanceof UserDetails) ? ((UserDetails) principal).getUsername() : principal.toString();
        return sessionRepository.findByPrincipalName(principalName)
            .stream()
            .map(session -> new SessionInformation(session.getPrincipal(), session.getId(), session.getLastAccessedTime()))
            .filter(info -> includeExpiredSessions || !info.isExpired())
            .collect(Collectors.toList());
    }

    @Override
    public SessionInformation getSessionInformation(String sessionId) {
        Session session = sessionRepository.findById(sessionId);
        if (session == null) return null;
        return new SessionInformation(session.getPrincipal(), session.getId(), session.getLastAccessedTime());
    }

    @Override
    public void refreshLastRequest(String sessionId) {
        sessionRepository.findById(sessionId).ifPresent(session -> {
            session.setLastAccessedTime(Instant.now());
            sessionRepository.save(session);
        });
    }

    @Override
    public void registerNewSession(String sessionId, Object principal) {
        // Spring Session handles creation
    }

    @Override
    public void removeSessionInformation(String sessionId) {
        sessionRepository.deleteById(sessionId);
    }
}