Redis – Spring Security 6 – Use JWT Tokens instead of JSESSIONID after OAuth2 Login

I’ve seen a couple of posts talking about something similar, though not exactly like what I’m trying to do. Namely I came across https://www.jessym.com/articles/stateless-oauth2-social-logins-with-spring-boot which is quite a complicated guide to still fit within Spring Security, and have what the author refers to as "stateless oauth2 logins". The issue with their approach is that it still relies on cookies, which I would rather avoid, as they are still vulnerable to things like CSRF attacks.

Here I’ve provided a graphic of what I’m trying to accomplish.

In the first section is what I’ve observed Spring Security’s default behavior to be ( I’m on Spring Security 6.2.0 ) with the following configuration and properties:

SecurityConfiguration.java:

@Configuration
public class SecurityConfiguration {

    private static final String[] SWAGGER_URLS = {
            "/v3/api-docs/**",
            "/swagger-ui/**",
            "/v2/api-docs/**",
            "/swagger-resources/**"
    };

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity, ClientRegistrationRepository clientRegistrationRepository) throws Exception {

        String base_uri = OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI;
        DefaultOAuth2AuthorizationRequestResolver resolver = new DefaultOAuth2AuthorizationRequestResolver(clientRegistrationRepository, base_uri);
        resolver.setAuthorizationRequestCustomizer(OAuth2AuthorizationRequestCustomizers.withPkce());

        return httpSecurity
                .authorizeHttpRequests(c -> {
                    // permit anyone to get to error pages
                    c.dispatcherTypeMatchers(DispatcherType.ERROR).permitAll();

                    // permit all swagger urls
                    c.requestMatchers(SWAGGER_URLS).permitAll();

                    // require authentication for all other cases
                    c.anyRequest().authenticated();
                })
                .oauth2Login(c -> {
                    c.authorizationEndpoint(auth -> auth.authorizationRequestResolver(resolver)); // use PKCE
                })
                .build();
    }

    // default SpringHttpFirewall is a bit too strict
    @Bean
    public HttpFirewall getHttpFirewall() {
        StrictHttpFirewall strictHttpFirewall = new StrictHttpFirewall();
        strictHttpFirewall.setAllowUrlEncodedDoubleSlash(true);
        return strictHttpFirewall;
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

(relevant) application.properties:

# GitHub OAuth2
spring.security.oauth2.client.registration.github.client-id=${GITHUB_CLIENT_ID}
spring.security.oauth2.client.registration.github.client-secret=${GITHUB_CLIENT_SECRET}
spring.security.oauth2.client.registration.github.scope=user:read

So, by default, I have observed that Spring will go through the whole OAuth2 authorization scheme, and then in the response to the callback ( redirect uri ), it will add a Set-Cookie with a JSESSIONID in it. This is stateful session management, and it stores all the data relating to the user in a Map or something in memory by default against the provided jsessionid.

I don’t like this for 2 reasons:

1. The sessions stored in memory will of course be wiped if the application shuts down for any reason. This can be remedied by storing session information in a database or redis, but then that’s an extra database request on every single authorized HTTP request to fetch the relevant information about the session.

2. Cookie-based authentication/authorization is in general vulnerable to CSRF attacks, since all cookies are sent along with whatever request is being made for the domain the cookie is stored for. This doesn’t change when https is involved, the cookies are just encrypted in that case, but they’re sent all the same. Having something like an Authorization header-based scheme means that any random request to an API won’t just be magically authenticated, it requires some javascript in the front-end to actually attach that header.

I want to address both of these by using JWT tokens provided in an Authorization header, instead of a JSESSIONID. The way I want to do this is, in the response from the callback from my app, I would like to provide the header along with a JWT token that I generate after I send the authorization code to the auth service and get back an access token. Note: the JWT I provide to the browser will not be the same as the access token I get from the auth service. That will be stored somewhere ( database, redis, w/e ) for later use, if necessary.

That about covers what I’m trying to accomplish. Please, if anyone’s done this before, or has relevant information/articles/documentation on how to get it done, I would appreciate it greatly. Thank you.