Why is Spring Security converting my 500 error to 403 when the UserService is down, and how can I ensure it returns the original 500 error?

There were some potentially ambiguous assumptions. I tried to guess the objectives.

You were using roles. Let me imagine. There were three roles in the system, e.g. ADMIN, EDITOR and USER.

I had some questions in mind:

If a service is up (returning HTTP status code 200), do you want people who have one of these roles to access /auth/login?

If a service is up (returning HTTP status code 200), do you want people who do not have one of these roles to access /auth/login?

If a service is down (returning HTTP status code 500), do you want people who have one of these roles to access /auth/login?

If a service is down (returning HTTP status code 500), do you want people who do not have one of these roles to access /auth/login?

My example code covered all these questions.

One test was to test when a service returned HTTP status code 200, and when people were not logged in, did they see 200 or 403?

Another test was to test when a service returned HTTP status code 500, and when people were not logged in, did they see 500 or 403?

Yet another test was to test when a service returned HTTP status code 200, and when people were logged in, did they see 200 or 403?

The last test was to test when a service returned HTTP status code 500, and when people were logged in, did they see 500 or 403?

    @Bean
    @Order(1000)
    public SecurityFilterChain securityFilterChainAuthLogin(HttpSecurity http) throws Exception{
        
        String[] matchedPaths = { 
            "/auth/login**"
        };
        
        http
            .csrf(csrf -> csrf.disable())
            .securityMatcher(
                matchedPaths
            )

            // If you want roles of "ADMIN", "EDITOR" or "USER" to enter...
            
            .authorizeHttpRequests(request -> 
                request
                    .requestMatchers(matchedPaths)
                    .hasAnyRole("ADMIN", "EDITOR", "USER")
                    .anyRequest()
                    .authenticated()
            )

            // If you want anyone to enter...

            // .authorizeHttpRequests(request -> 
            //     request
            //         .requestMatchers(matchedPaths)
            //         .permitAll()
            // )

            .sessionManagement(session -> session
                .sessionConcurrency((concurrency) -> concurrency
                                .maximumSessions(1)
                                .maxSessionsPreventsLogin(true)
                        )
            )
            .logout(logout -> logout.logoutUrl("/logout"));
            
        return http.build();
    }

In my example, using Microsoft SQL Server, I ran a SQL statement CREATE DATABASE springbootsecurityverify403 COLLATE Latin1_General_100_CS_AI_WS_SC_UTF8; to create the database before running Spring Boot. The objectives were to make the service return HTTP status code 200 or 500 respectively and to observe what I could see. I opened http://localhost:8080/ in the browser to test.

The results in testing POST /auth/login were:

Using .permitAll() meant I did not need to log in and I could get 200 or 500.

Using .hasAnyRole("ADMIN", "EDITOR", "USER").anyRequest().authenticated() meant when I was not logged in, I got 403. After I logged in, I got 200 or 500.

What I tried to show was a part of Spring Boot Security appeared to work as expected in the above ways.

The permissions were set using @Order and matching paths as well as matching roles as in my example. You might follow such an example and if you still notice other strange HTTP status code 403 problems, there could be other issues in other parts of the code, which you might want to share for other people to give potentially more helpful answers.