SecurityContextHolder란

Spring Security 사용 시 SecurityContextHolder를 통해 인증 정보를 저장하고 가져오게 되는데 어떤 방식으로 Authentication을 저장하는지 간략하게 알아보자.

 

계층 구조

인증된 사용자 정보인 Principal을 Authentication에서 관리, Authentication을 SecurityContext에서 관리, SecurityContext는 SecurityContextHolder가 관리한다.

ThreadLocal을 사용하여 Authentication을 저장한다.(한 스레드 내에서 사용하는 공용 저장소) 이를 통해 Authentication을 한 스레드 내에서 공유한다. 즉, 스레드가 달라지면 제대로 된 인증 정보를 가져올 수 없다.

ThreadLocal 모드

모드 설명

MODE_THREADLOCAL	기본. 스레드마다 독립 저장소
MODE_INHERITABLETHREADLOCAL	자식 스레드도 인증 정보 상속
MODE_GLOBAL	전역 저장 — 거의 안 씀, 위험함

 

 

요청이 끝나면 Spring Security FilterChain의 마지막 단계에서 SecurityContextHolder.clearContext() 호출되어 인증 정보 제거됨.

 

캐시 사용 여부

SecurityContextHolder.clearContext()를 호출 하므로 모든 Authentication 방식에서 캐시는 존재하지 않는것인지?

방식	SecurityContext 캐시	매 요청 인증 비용
세션 기반	있음 (HTTP Session)	낮음 — 세션만 확인
JWT 기반	없음	중간 — JWT 서명 검증만 수행

 

그래서 뭐냐면

SecurityContextHolder는 스레드와 SecurityContext를 연결해주어 Authentication을 저장할 수 있는데, 스레드가 달라지면 인증 정보를 가져올 수 없으니, 런타임 시 SecurityContextHolderStrategy라는 인터페이스의 구현체들에게 스레드와 SecurityContext를 어떻게 연결시킬지에 대한 전략을 위임하며, 각 요청 실행 컨텍스트마다 인증 정보가 안전하게 격리되고 필요한 시점에 정확한 SecurityContext를 반환하도록 동작한다.