Is a SecurityContext shared between requests when using Spring Security?

Question

I'm seeing some strange behaviour when using stateless token-based authentication on a rest API written using Spring Boot.

The client includes a JWT token with each request, and a custom filter I've written that extends GenericFilterBean adds an Authentication object based on the claims in the token to the security context using the following :

SecurityContextHolder.getContext().setAuthentication(authentication);

And clears the context after processing the request by doing :

SecurityContextHolder.getContext().setAuthentication(null);

However when the simple app I've developed performs a range of operations, I sometimes see that the security context isn't being set correctly - sometimes it's null for a request that has supplied a token. The filter is being called correctly, setAuthencation() is also being called, but the request fails authentication, and throws a 403 denied.

If I explicitly turn off any http Session management by setting the session creation policy to STATELESS, this behaviour stops.

Any ideas what could be happening here? Is the security context being shared between threads dealing with requests in some way?

Loosen

Did you check this? #16953218 – Od

Answer 1

It seems that the context can be shared, according the official documentation here : http://docs.spring.io/spring-security/site/docs/3.1.x/reference/springsecurity-single.html

In an application which receives concurrent requests in a single session, the same SecurityContext instance will be shared between threads. Even though a ThreadLocal is being used, it is the same instance that is retrieved from the HttpSession for each thread. This has implications if you wish to temporarily change the context under which a thread is running. If you just use SecurityContextHolder.getContext(), and call setAuthentication(anAuthentication) on the returned context object, then the Authentication object will change in all concurrent threads which share the same SecurityContext instance. You can customize the behaviour of SecurityContextPersistenceFilter to create a completely new SecurityContext for each request, preventing changes in one thread from affecting another. Alternatively you can create a new instance just at the point where you temporarily change the context. The method SecurityContextHolder.createEmptyContext() always returns a new context instance.

Loosen