SecurityContext & SecurityContextHolder (Spring Security 6)

SecurityContext

Authentication은 SecurityContext에 저장되며 이 SecurityContext는 SecurityContextHolder를 통해 참조 및 설정할 수 있다. 이로써 어플리케이션에서 현재 인증된 사용자의 인증 정보/상태/권한 등을 확인할 수 있다.

출처: https://docs.spring.io/spring-security/reference/servlet/authentication/architecture.html#servlet-authentication-securitycontext

SecurityContextHolder

• Spring Security 인증 모델의 핵심이다. Spring Security가 인증된 사용자에 대한 세부 정보를 저장하는 곳
• 내부적으로 ThreadLocal을 가지고 있으며 인증된 사용자의 Authentication 객체를 담고 있는 SecurityContext 객체를 저장한다.
• SecurityContextHolderStrategy 를 이용하여 다양한 저장 전략을 지원
  
  

1) MODE_THREADLOCAL - ThreadLocal에 저장(기본 전략)

• 각 스레드가 독립적인 보안 컨텍스트를 가지며 대부분의 웹/서버 환경에 적합함

2) MODE_INHERITABLETHREADLOCAL

• 부모 스레드로부터 자식 스레드로 보안 컨텍스트가 상속되며 작업을 스레드 간 분산 실행하는 경우 유용
• 기본적으로 부모 스레드와 자식 스레드 모두 각각의 고유한 ThreadLocal을 가지고 있기 때문에 부모 스레드가 가진 SecurityContext를 자식 스레드가 자동으로 전달되지 않지만, 해당 모드를 사용하면 자식 스레드에서 부모 스레드의 SecurityContext를 참조할 수 있음

3) MODE_GLOBAL

• 전역적으로 단일 보안 컨텍스트를 사용하며(즉, 모든 스레드가 단일 SecurityContext를 공유) 서버 환경에서는 부적합하며 주로 간단한 어플리케이션에 적합함

위 3개의 전략 모드 중 하나를 직접 지정하고 싶다면 SecurityContextHolder.setStrategyName(String) 을 사용하면 됨 → 위의 3개의 전략 중 1개를 파라미터로 넘기면 됨

※ ThreadLocal : 각 Thread마다 가지고 있는 고유한 저장소로서 동시성 문제를 해결함

SecurityContext 참조 및 삭제

Spring Security 이전 버전과 달리 SecurityContext를 참조하거나 삭제하려면 getContextHolderStrategy() 를 사용해야 한다.

• 참조: SecurityContexHolder.getContextHolderStrategy().getContext()
• 삭제: SecurityContexHolder.getContextHolderStrategy().clearContext()
• Supplier<SecurityContext> getDeferredContext( ) → Supplier를 사용함으로써 필요할 때(Supplier 실행 시점)에 SecurityContext를 얻기 때문에 성능 상의 이점이 생김

구조

• 스레드마다 할당되는 전용 저장소에 SecurityContext를 저장하기 때문에 동시성의 문제가 없음
• 스레드 풀에서 운용되는 스레드일 경우 새로운 요청이더라도 기존의 ThreadLocal이 재사용될 수 있기 때문에 클라이언트 응답 직전에 항상 SecurityContext를 삭제해주고 있음