작성한 질문수 11

0

핵심을 말씀드리자면 ThreadLocal 은 요청범위에서만 유효한 저장소이기 때문에 요청때마다 인증을 계속 유지하지 못합니다.

그러나 세션은 세션자체가 만료되지 않는 이상 계속 유지가 되기 때문에 요청때마다 인증을 계속 유지할 수있습니다.

그래서 인증객체를 ThreadLocal 에 저장하고 나서 다시 세션에 저장해야만 요청 때마다 인증을 다시 하지 않아도 됩니다.

이 부분은 강의에서 여러번 설명하고 있으니 참고해 주세요

0

안녕하세요, 인프런 AI 인턴입니다. 박주형님 질문에 대해 답변드리겠습니다.

스프링 시큐리티에서 SecurityContext는 현재 사용자에 대한 인증 정보를 저장하기 위한 구조입니다. 이를 관리하기 위해 두 가지 주요 메커니즘이 있는데요, SecurityContextHolder와 SecurityContextRepository가 그것입니다.

1. SecurityContextHolder:

   • 이 메서드는 주로 애플리케이션 내의 인증 처리를 위해 사용됩니다.
     
   • 내부적으로 ThreadLocal 변수를 사용하여 인증 객체를 현재 실행 중인 스레드에 저장합니다. 이는 현재 스레드의 데이터를 안전하게 유지하며, 각 요청이 다른 스레드에서 처리될 때 서로의 인증 정보를 침범하지 않도록 합니다. 따라서 멀티쓰레딩 환경에서 각 사용자의 인증 정보를 격리해서 관리할 수 있습니다.
     

2. SecurityContextRepository:

   • 이 메서드는 애플리케이션의 범위를 넘어 세션 등 외부 저장소에 인증 정보를 저장하고 복원할 때 사용됩니다.
     
   • 예를 들어, HTTP 세션을 통해 사용자의 인증 상태를 유지합니다. 사용자의 인증 세션이 지속되는 동안 새 요청마다 세션에서 인증 정보를 가져와 사용할 수 있습니다. 이는 지속적인 로그인 상태를 유지하기 위함입니다.
     

그러므로 두 방법은 각각 다른 범위와 지속성을 염두에 두고 설계되었습니다. SecurityContextHolder는 현재 요청/응답 사이클에 유효한 인증 정보를 스레드별로 관리하고, SecurityContextRepository는 이 정보를 세션 등에 저장하여 더 장기적인 인증 상태를 관리합니다.

관련해서 더 상세한 정보가 있는 기존 질문 답변을 추천드립니다:
- SecurityContextHolder 관련 질문이 있습니다!
- Session 과 SecurityContext에 관련된 질문입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.