Security Top

I just announced the new Learn Spring Security course, including the full material focused on the new OAuth2 stack in Spring Security 5:


1. Overview

In this article, we're going to illustrate how Spring Security allows us to control our HTTP Sessions.

This control ranges from a session timeout to enabling concurrent sessions and other advanced security configs.

Further reading:

Retrieve User Information in Spring Security

How to get the currently logged in user with Spring Security.

Spring Security Remember Me

Cookie Remember Me example with Spring Security.

Spring Security Logout

Spring Logout Example - how to configure the logout url, the logout-succcess-url and how to use a custom bean to handle advanced logout scenarios.

2. When Is the Session Created?

We can control exactly when our session gets created and how Spring Security will interact with it:

  • always – a session will always be created if one doesn't already exist
  • ifRequired – a session will be created only if required (default)
  • never – the framework will never create a session itself but it will use one if it already exists
  • stateless – no session will be created or used by Spring Security
<http create-session="ifRequired">...</http>

Java configuration:

protected void configure(HttpSecurity http) throws Exception {

It's very important to understand that this configuration only controls what Spring Security does – not the entire application. Spring Security may not create the session if we instruct it not to, but our app may!

By default, Spring Security will create a session when it needs one – this is “ifRequired“.

For a more stateless application, the “never” option will ensure that Spring Security itself will not create any session; however, if the application creates one, then Spring Security will make use of it.

Finally, the strictest session creation option – “stateless” – is a guarantee that the application will not create any session at all.

This was introduced in Spring 3.1 and will effectively skip parts of the Spring Security filter chain – mainly the session related parts such as HttpSessionSecurityContextRepository, SessionManagementFilter, RequestCacheFilter.

These more strict control mechanisms have the direct implication that cookies are not used and so each and every request needs to be re-authenticated. This stateless architecture plays well with REST APIs and their Statelessness constraint. They also work well with authentication mechanisms such as Basic and Digest Authentication.

3. Under the Hood

Before executing the Authentication process, Spring Security will run a filter responsible with storing the Security Context between requests – the SecurityContextPersistenceFilter. The context will be stored according to a strategy – HttpSessionSecurityContextRepository by default – which uses the HTTP Session as storage.

For the strict create-session=”stateless” attribute, this strategy will be replaced with another – NullSecurityContextRepository – and no session will be created or used to keep the context.

4. Concurrent Session Control

When a user that is already authenticated tries to authenticate again, the application can deal with that event in one of a few ways. It can either invalidate the active session of the user and authenticate the user again with a new session, or allow both sessions to exist concurrently.

The first step in enabling the concurrent session-control support is to add the following listener in the web.xml:


Or define it as a Bean – as follows:

public HttpSessionEventPublisher httpSessionEventPublisher() {
    return new HttpSessionEventPublisher();

This is essential to make sure that the Spring Security session registry is notified when the session is destroyed.

To enable the scenario which allows multiple concurrent sessions for the same user the <session-management> element should be used in the XML configuration:

<http ...>
        <concurrency-control max-sessions="2" />

Or, via Java configuration:

protected void configure(HttpSecurity http) throws Exception {

5. Session Timeout

5.1. Handling the Session Timeout

After the session has timed out, if the user sends a request with an expired session id, they will be redirected to a URL configurable via the namespace:

    <concurrency-control expired-url="/sessionExpired.html" ... />

Similarly, if the user sends a request with a session id which is not expired, but entirely invalid, they will also be redirected to a configurable URL:

<session-management invalid-session-url="/invalidSession.html">

The corresponding Java configuration:


5.2. Configure the Session Timeout with Spring Boot

We can easily configure the Session timeout value of the embedded server using properties:


If we don't specify the duration unit, Spring will assume it's seconds.

In a nutshell, with this configuration, after 15 minutes of inactivity, the session will expire. The session after this period of time is considered invalid.

If we configured our project to use Tomcat, we have to keep in mind that it only supports minute precision for session timeout, with a minimum of one minute. This means that if we specify a timeout value of 170s for example, it will result in a 2 minutes timeout.

Finally, it's important to mention that even though Spring Session supports a similar property for this purpose (spring.session.timeout), if that's not specified then the autoconfiguration will fallback to the value of the property we first mentioned.

6. Prevent Using URL Parameters for Session Tracking

Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).

Starting with Spring 3.0, the URL rewriting logic that would append the jsessionid to the URL can now be disabled by setting the disable-url-rewriting=”true” in the <http> namespace.

Alternatively, starting with Servlet 3.0, the session tracking mechanism can also be configured in the web.xml:


And programmatically:


This chooses where to store the JSESSIONID – in the cookie or in a URL parameter.

7. Session Fixation Protection With Spring Security

The framework offers protection against typical Session Fixation attacks by configuring what happens to an existing session when the user tries to authenticate again:

<session-management session-fixation-protection="migrateSession"> ...

The corresponding Java configuration:


By default, Spring Security has this protection enabled (“migrateSession“) – on authentication a new HTTP Session is created, the old one is invalidated and the attributes from the old session are copied over.

If this is not the desired behavior, two other options are available:

  • when “none” is set, the original session will not be invalidated
  • when “newSession” is set, a clean session will be created without any of the attributes from the old session being copied over

8. Secure Session Cookie

Next, we'll discuss how to secure our session cookie.

We can use the httpOnly and secure flags to secure our session cookie:

  • httpOnly: if true then browser script won't be able to access the cookie
  • secure: if true then the cookie will be sent only over HTTPS connection

We can set those flags for our session cookie in the web.xml:


This configuration option is available since Java servlet 3. By default, http-only is true and secure is false.

Let's also have a look at the corresponding Java configuration:

public class MainWebAppInitializer implements WebApplicationInitializer {
    public void onStartup(ServletContext sc) throws ServletException {
        // ...

If we're using Spring Boot, we can set these flags in our


Finally, we can also achieve this manually by using a Filter:

public class SessionFilter implements Filter {
    public void doFilter(
      ServletRequest request, ServletResponse response, FilterChain chain)
      throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse res = (HttpServletResponse) response;
        Cookie[] allCookies = req.getCookies();
        if (allCookies != null) {
            Cookie session = 
     -> x.getName().equals("JSESSIONID"))

            if (session != null) {
        chain.doFilter(req, res);

9. Working With the Session

9.1. Session Scoped Beans

A bean can be defined with session scope simply by using the @Scope annotation on beans declared in the web-Context:

public class Foo { .. }

Or with XML:

<bean id="foo" scope="session"/>

Then, the bean can simply be injected into another bean:

private Foo theFoo;

And Spring will bind the new bean to the lifecycle of the HTTP Session.

9.2. Injecting the Raw Session into a Controller

The raw HTTP Session can also be injected directly into a Controller method:

public void fooMethod(HttpSession session) {
    session.setAttribute(Constants.FOO, new Foo());
    Foo foo = (Foo) session.getAttribute(Constants.FOO);

9.3. Obtaining the Raw Session

The current HTTP Session can also be obtained programmatically via the raw Servlet API:

ServletRequestAttributes attr = (ServletRequestAttributes) 
HttpSession session= attr.getRequest().getSession(true); // true == allow create

10. Conclusion

In this article, we discussed managing Sessions with Spring Security. Also, the Spring Reference contains a very good FAQ on Session Management.

As always, the code presented in this article is available over on Github. This is a Maven-based project, so it should be easy to import and run as it is.

Security bottom

I just announced the new Learn Spring Security course, including the full material focused on the new OAuth2 stack in Spring Security 5:

Newest Most Voted
Inline Feedbacks
View all comments
Science vine
Science vine
6 years ago

Thank you for your great explanations.

Joe Eugene
Joe Eugene
5 years ago
Reply to  Science vine

Thanks for great blog!

How do we get spring security to share session in same domain and context path? (test1.war) (test2.war)

User logs to test1 and should not be asked to login to test2. Tried setting cookie path to “/app/” and test2 spring security receives cookie set by test1 but does not associate with previous http session and redirects to test2 login.

How can this be solved without CAS/SSO/Database session or Remember me implementation?

Eugen Paraschiv
5 years ago
Reply to  Joe Eugene

There’s a good piece I covered in last weeks review on externalizing the session information with the new spring-session project. Hope it helps. Cheers,

5 years ago

This is really a great blog. It does help me to understand session management in spring security.

I want to implement the spring security in RESTful service. A third party will validate (so we will use preauth in spring-secuirty) user and will pass the token to our app.

But we still want to store some cookie between the requests. How can we do that? I read that RESTful service should use create-session=”stateless” to be stateless?

Eugen Paraschiv
5 years ago
Reply to  AK

This is a complex topic, and there’s no one answer. If you’re thinking from the point of view of strict adherence to REST as architectural constraint, then the server side should be entirely stateless – so no cookies. Every request passes in credentials (if we’re talking about – for example – Digest auth). Of course that does come with complexity and potential vulnerabilities with managing these credentials on the client side. The proxy solution – discussed in this ongoing series on the Spring blog addresses that (I think it was article 4). Alternatively – you can go the cookie route… Read more »

Matt Krevs
Matt Krevs
6 years ago

Nice work again. I didnt know about the expired-url feature.

One small typo. Change “the application can deal with that even in one of a few ways” to “the application can deal with that event in one of a few ways”.

Eugen Paraschiv
6 years ago
Reply to  Matt Krevs

Hey Matt – nice catch, thanks. Corrected.

6 years ago

mvn build only for spring-security-mvn-session and trying to open homepage.jsp but

HTTP Status 404 –
description The requested resource is not available.

Any suggestion how to proceed ??

Eugen Paraschiv
6 years ago
Reply to  AKS

Hey AKS – I just tried to run that project and access the page – I was able to do that without any problems at I’m able to log in here: http://localhost:8080/spring-security-mvc-session/login.html
How exactly are you deploying? Are you doing anything from within the IDE or perhaps using a stand-alone server? Cheers,

6 years ago

I need to use cookies instead of httpsession with spring security, that is for using cookies for stateless authentication.
Do anyone have any idea of how to do it or provide any help?

Eugen Paraschiv
6 years ago
Reply to  Mohsen

Hey Mohsen – a few things to note related to your question. First – cookies and httpsession don’t have a one-or-the-other type of relation. In fact – the session usually works alongside the client side cookie. Second – if you are considering a stateless authentication mechanism – then httpsession is not the way to go, because the httpsession is state. Stateless would mean that you don’t have any kind of httpsession and that you simply send your credentials along with every request. Hope that clears up a few things – I would further recommend you do some additional, in depth… Read more »

Anant Navagale
Anant Navagale
6 years ago

Hi, I am using spring 4 and spring security 3.2… I want to validate session on every request coming on tomcat server. I wan to check 1) current request is coming from same IP address from where authentication happened 2) When authentication happened, I stored some values like user id, some keys (in encrypted format). I want to validate these values in every request. 3) I also want to use server side cookies and validate them on every request. 4) If session is expired I want user be prompted to enter authentication to continue the work 5) If any of… Read more »

Eugen Paraschiv
6 years ago
Reply to  Anant Navagale

Hey Anant, 1. You can write security expressions to check IP addresses, but for dynamic checking like that, there’s nothing out of the box. You’ll need to: – keep track of the IP address of the first authentication – a simple cache would make sense, or the DB of you need to re-use that later on – write your custom check logic, probably in a custom auth provider 2. Same – once you do one custom check, it’s easy to add more 3. not sure what you mean by server side cookie – cookies will implicitly be sent to the… Read more »

Comments are closed on this article!