The first configuration detail that needs to be decided is when the session will be created. Spring Security 4.2.2 supports multiple ways of creating sessions:

• Always during transactions without any constraints (SessionCreationPolicy.ALWAYS)
• Only when required by the application (SessionCreationPolicy.IF_REQUIRED)
• Stop creating any but use existing sessions (SessionCreationPolicy.NEVER)
• Stop creating nor use sessions during the entire lifespan of the application (SessionCreationPolicy.STATELESS)

Among these four types, the SessionCreationPolicy.IF_REQUIRED fits with login-based applications.

The next decision is how to control the concurrent access to the application. With the help of HttpSessionEventPublisher, the architecture offers developers control through http.sessionManagement().maximumSession(). Once a user reaches this limit, HttpSecurity has the option to offer http.sessionManagement().maxSessionsPreventsLogin(true) to the user or not but, either of the options can lead to /session_expired.html.

On the other hand, it is always recommended to enable URL rewriting in any MVC application for cases in which the browser is restricted to run cookies. Whether ServletContext stores the session as Cookie in the browser, or as a request parameter in a URL, it is always advisable to use http.sessionManagement().enableSessionUrlRewriting(true) to avoid possible runtime exceptions when the browser's cookies support is disabled.

Lastly, it is important that after /logout, all sessions must be invalidated or killed for security reasons. http.logout().invalidateHttpSession(true) is applicable to deleting all types of sessions, while http.logout().deleteCookies("JSESSIONID") only applies once the application is in SessionTrackingMode.COOKIE mode.