Expected Behavior
Oauth2 client should close and clean the HttpSession it created after the authorization code flow is finished.
Current Behavior
If I set sessionCreationPolicy to SessionCreationPolicy.STATELESS and after an authorization code flow finishes successfully, the HttpSession created is still active and the STATELESS policy flag is ignored. The java servlet session is being created at this line.
The JSESSIONID cookie is present in every future request after the authorization flow has finished. This causes future requests, that use a JWT token and are stateless, to be directed to the same pod if sticky sessions are configured on the load balancer. The sticky session on the load balancer should only be needed to complete the authentication flow when the default implementation is used.
Current workaround:
Use a login success handler where the java servlet session gets cleaned:
request.getSession().invalidate()
Cookie cookie = new Cookie("JSESSIONID", "");
cookie.setMaxAge(0);
cookie.setPath(request.getContextPath());
response.addCookie(cookie);
Expected Behavior
Oauth2 client should close and clean the HttpSession it created after the authorization code flow is finished.
Current Behavior
If I set sessionCreationPolicy to SessionCreationPolicy.STATELESS and after an authorization code flow finishes successfully, the HttpSession created is still active and the STATELESS policy flag is ignored. The java servlet session is being created at this line.
The JSESSIONID cookie is present in every future request after the authorization flow has finished. This causes future requests, that use a JWT token and are stateless, to be directed to the same pod if sticky sessions are configured on the load balancer. The sticky session on the load balancer should only be needed to complete the authentication flow when the default implementation is used.
Current workaround:
Use a login success handler where the java servlet session gets cleaned: