SecurityContext를 새로 만들어야 할까?

[f1v3-dev]

궁금했던 점

JWT 검증 필터 부분 코드를 리팩토링하면서 다음과 같은 의문이 들었다.

        // 1번 방법 : 새로운 SecurityContext 생성
        SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
        securityContext.setAuthentication(authToken);
        SecurityContextHolder.setContext(securityContext);

        // 2번 방법 : 기존 SecurityContext 사용
        SecurityContextHolder.getContext().setAuthentication(authToken);

대부분의 JWT 검증 필터 구현 코드를 찾아보면, 2번 방법을 사용하는 것으로 보여진다.
우리 프로젝트에서는 1번 방법으로 구현을 했었지만, 2번 방법으로 변경해도 아무런 문제가 없이 동작한다.

여기서 드는 의문은, 어느 시점에 SecurityContextHolder 에 SecurityContext 를 생성하고 넣어준 것인가?
또한, 1번 방법이 아닌 2번 방법을 사용하는 이유는 뭘까?

필터 체인의 동작

필터 체인의 동작을 봐보자.

@EnableWebSecurity(debug = true) 을 SecurityConfig 클래스에 설정해준 후 확인해보았다.

Filter Chain 동작

Security filter chain: [
  DisableEncodeUrlFilter
  WebAsyncManagerIntegrationFilter
  SecurityContextHolderFilter  // (1)
  HeaderWriterFilter
  CorsFilter
  LogoutFilter
  OAuth2AuthorizationRequestRedirectFilter
  OAuth2LoginAuthenticationFilter
  JwtAuthenticationFilter    // (2)
  RequestCacheAwareFilter
  SecurityContextHolderAwareRequestFilter
  AnonymousAuthenticationFilter
  SessionManagementFilter
  ExceptionTranslationFilter
  AuthorizationFilter
]

여기서 우리가 주목해야 하는 필터는 (1) SecurityContextHolderFilter 이다.
해당 필터는 이름에서 알 수 있듯이 SecurityContextHolder 와 관련된 작업을 하는 필터이다.

내부 코드를 한 번 확인해보자.

SecurityContextHolderFilter

필터의 doFilter 메서드

	@Override
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
			throws IOException, ServletException {
		doFilter((HttpServletRequest) request, (HttpServletResponse) response, chain);
	}

	private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
			throws ServletException, IOException {
		if (request.getAttribute(FILTER_APPLIED) != null) {
			chain.doFilter(request, response);
			return;
		}
		request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
		Supplier<SecurityContext> deferredContext = this.securityContextRepository.loadDeferredContext(request);
		try {
			this.securityContextHolderStrategy.setDeferredContext(deferredContext);
			chain.doFilter(request, response);
		}
		finally {
			this.securityContextHolderStrategy.clearContext();
			request.removeAttribute(FILTER_APPLIED);
		}
	}

위 코드에서 집중해서 봐야 할 부분은

1. securityContextRepository 에서 컨텍스트를 불러오고
2. securityContextHolderStrategy 를 통해 컨텍스트를 저장

하는 부분이다.

GPT의 내용을 빌려보자면

이렇게 알 수 있듯이, SecurityContextHolderFilter 에서 미리 사용할 SecurityContext 를 생성하고 SecurityContextHolder 에서 들고있는 것을 알 수 있다.

그렇다면, 어떤 방식이 맞는 방식일까?

정답은 없는 것 같다.

하지만, 현 시점 우리 프로젝트에서는 JWT 검증 필터 이전까지 SecurityContext 에 접근해서 Authentication 정보를 넣는 작업을 하지 않고 있다.
즉, 초기의 상태를 유지하고 있는 상태로 JWT 검증 필터까지 오게 되는 것이다.

이러한 상황에서는 굳이 새로운 컨텍스트를 생성(SecurityContext)하고 SecurityContextHolder 에 넣어주는 작업은 불필요할 것이라고 판단이 된다.

물론, 현재 컨텍스트에 필요한 정보가 담겨져 있을 경우 (새로운 필터가 도입되는 등의 문제로) 원하지 않는 동작을 할 것이라고 판단이 된다.

결론

SecurityContextHolder.getContext() 를 불러오는 방식이 더 효율적인 것이라고 판단이 된다.

제 말이 무조건 맞다는건 아니고 다른 생각이 있으면 공유해주세요!