개발 블로그
article thumbnail
Published 2023. 4. 26. 20:05
[TIL] DAY 24 항해99

스프링 시큐리티에 대해 학습하던 중 의문이 생겼다. 학습한 내용을 바탕으로 생각했을 때 Security Context 에 있는 인증 객체(Authentication)를 통해 인증이나 인가와 관련된 처리를 하는 것으로 이해했다.

 

그런데 우리가 만들 서비스의 유저는 1명이 아닌데 모든 유저들의 인증 객체가 하나의 Security Context 에 저장이 된다면 어떤 인증 객체가 어떤 유저에 대한 정보를 가지고 있는지를 어떻게 구분하는 걸까?? 

 

과거에 세션, 쿠키를 이용한 인증 방식에서 하나의 Sesseon ID 마다 서버에 하나의 세션 저장소가 만들어지고 이 저장소 안에 담긴 객체를 통해 인증이 이루어진다고 학습했다.

 

그래서 Security Context 에서도 이와 유사하게 하나의 Sesson ID 와 하나의 인증 객체가 매칭되어 이를 기반으로 찾는 걸까? 라는 생각을 했다.

 

조사해보니 session id와는 무관하였고 스레드를 기준으로 구분을 할 수 있었다.

 

 

 

스프링 시큐리티를 통해 만든 인증 객체(Authentication)는 SecurityContext 에 저장이 되고 SecurityContext는 SecurityContextHolder 라는 것으로 감싸져 이 Holder를 통해서 Context에 접근이 가능하다.

 

SecurityContextHolder는 전역 객체이고 이 안에 SecurityContext를 저장하는 방식에는 3가지가 있다.

 

1. MODE_THREADLOCAL : 스레드 당 SecurityContext 객체를 할당(default)

2. MODE_INHERITABLETHREADLOCAL : 메인 스레드와 자식 스레드에 관하여 동일한 SecurityContext를 유지

3. MODE_GLOBAL : application에서 단 하나의 SecurityContext를 저장

 

default 방식인 THREADLOCAL 방식을 보면 스레드 별로 서로 다른 SecurityContext 가 할당된다. 멀티스레드 환경이든 싱글스레드 환경이든 어찌됐건 사용자들이 하나의 스레드를 공유하지는 않으므로 유저마다 별개의 SecurityContext 를 할당받게되는 것이다.

 

 

'항해99' 카테고리의 다른 글

[TIL] DAY 27  (0) 2023.04.29
[TIL] DAY 25  (0) 2023.04.27
[TIL] DAY 22  (0) 2023.04.24
[WIL] 항해 3주차  (0) 2023.04.23
[TIL] DAY 17  (0) 2023.04.20
profile

개발 블로그

@하얀.손

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!