5.7 이후로 Deprecated 되었습니다.

이 부분은 저도 좀 더 자세히 봐야 하는데 일단 현재 제가 이해한 바로는 이전 버전에서는 시큐리티에서 세션을 사용한다고 가정했을 때 시큐리티가 자동적으로 SecurityContext 를 세션에 저장을 해 주었습니다.

그리고 그 역할을 하는 클래스가 SecurityContextPersistenceFilter 였고 내부적으로 HttpSessionSecurityContextRepository 가 세션을 저장하는 역할을 담당했습니다.
그래서 인증 받은 사용자가 서버에 접속했을 때 세션으로부터 SecurityContext 를 꺼내어 참조해서 인증을 계속 유지하도록 처리가 되었습니다.

그런데 시큐리티 최신 버전에서도 시큐리티에서 제공하는 인증필터, 예를 들면 UsernamePasswordAuthenticationFilter 를 사용해서 인증을 하게 되면 여전히 세션에 SecurityContext 를 저장하고 있습니다. 즉 세션 기반의 인증처리를 지원하고 있습니다.

다만 이전 버전과 한가지 차이점이라면 어떤 인증처리를 위해 개발자가 직접 인증 필터를 만들었을 경우 사용자가 이 필터를 통해 인증처리를 한다면 더 이상 시큐리티가 자동적으로 SecurityContext 를 세션에 저장해 주지 않는다는 것입니다.

기본은 ThreadLocal 에만 저장하고 요청에 대한 응답이 완료된 이후에는 ThreadLocal 에서 SecurityContext 를 삭제해 버리기 때문에 Scope 즉 범위가 Request 에 한정되게 됩니다.
그래서 "Spring Security'는 'SecurityContext'의 생명주기를 'HTTP Request'와 동일하게 관리할 수 있게 되었다" 라는 의미가 될 수 있습니다.
Request 의 생명주기가 곧 요청마다 생성되는 스레드의 보관장소인 ThreadLocal 이라 할 수 있습니다.

이 경우도 시큐리티에서 제공하는 AbstractAuthenticationProcessingFilter 를 상속해서 인증필터를 만들었을 때 이고 만약 인증필터를 시큐리티에서 제공하는 클래스를 상속하거나 구현하는 것이 아닌 완전히 새로운 것을 만들었을 때에는 별도로 SecurityContextRepository 구현체를 할당해 주어야 합니다.
(이부분은 내용이 좀 길어 여기서 설명하기 힘든 점 양해 부탁드립니다.)

그래서 최신 버전에서는 사용자가 직접 정의한 인증 필터를 만들어서 인증처리를 할 경우 세션에 SecurityContext 를 저장할 것인지 아닌지를 선택할 수 있고 그 선택에 따라 인증 처리 방식을 유연하게 가져 갈 수 있습니다.

보통 JWT 토큰을 이용한 인증방식은 세션을 사용하지 않기 때문에 별도의 JWT 인증 필터를 만들더라도 기본적으로 세션을 사용하지 않도록 되어 있기 때문에 개발자가 명확하게 세션을 사용할 것인지 아닌지의 정책을 확실하게 정해야 한다는 의미이기도 합니다.