An authenticated browser session must not keep an identifier that could have been fixed before login.
Spring Security login session: rotate the identifier at authentication
Watch the transition
A browser can have a session before login for a saved request or CSRF token. On successful authentication, Spring Security's session fixation protection changes the session ID on modern Servlet containers. The old identifier must not remain a usable authenticated session. This is distinct from CSRF protection: one stops a known pre-login session ID from becoming an authenticated handle; the other protects state-changing browser requests.
Keep the default unless the application proves otherwise
Custom authentication filters and manual SecurityContext persistence can alter when the authenticated context is saved. Test the entire login path, including the response cookie, old-cookie rejection and logout. A reverse proxy must preserve secure cookie behavior and HTTPS detection; forwarded-header trust is part of that deployment.
Use a realistic browser test
Capture the session cookie before login, authenticate, and compare it with the post-login cookie. Retry a protected route using only the old cookie and require rejection. Repeat after logout. This lesson is a test plan and sketch; no running browser flow is claimed.
Implementation sketch
MockHttpSession beforeLogin = new MockHttpSession();
String oldId = beforeLogin.getId();
MvcResult authenticated = mockMvc.perform(post("/login")
.session(beforeLogin)
.with(csrf())
.param("username", "shift-lead")
.param("password", password))
.andReturn();
assertNotEquals(oldId, authenticated.getRequest().getSession().getId());Cost and verification
Changing a session identifier is cheap. Shared session storage, concurrent session control and invalidation behavior need their own load and failover checks.
Common Mistakes
- Do not disable session fixation protection to keep a pre-login cookie stable.
- Do not assume JWT stateless APIs use the browser-session policy.
- Do not claim safety from an ID-change assertion without checking the old ID cannot authorize.
Read next
Spring Security OAuth2 login: callback, identity and browser session, Spring Security CSRF: protect cookie-authenticated writes, Spring behind a proxy: trust forwarded headers only after the edge strips them, Spring Security filter chain: authentication, CSRF and request order.
