원리를 공부하다가 조금 이해 안가는 부분이 있어요
유저는 서버에 요청할 때마다 token을 함께 전송.
서버는 요청을 받을때마다 token 검증
(만료여부, 위/변조여부 검증, payload의 audience를 통해 유저 id 획득)
이때 문제가 없다면 최종적으로 security context holder에 사용자 정보를 입력하잔슴?
근데 이렇게 security context holder에 authentication을 세팅하는 것도 당연히 토큰 검증과 마찬가지로 매 요청마다 하게 될텐데
이 인증정보가 하나의 요청을 처리할 동안만 유효해서 이렇게 매 요청마다 인증정보를 넣어주는 거임?
애초에 security context holder라는 객체의 생명주기가 원래 이런건지 궁금함..
음 스프링을 안하지만 비슷한 개념일거 같아서 써봄 http는 기본적으로 stateless 하기때문에 서버에선 각 요청이 누구로부터 왔는지 알 수 있는 방법이 없음 그렇기때문에 매 요청에 내가 누구요 하는 토큰을 담아서 서버에게 알리는 것이고.. HTTP 요청은 스프링의 요청 처리 사이클을 따라 흐르겠지 끝까지 돌고 나면 메모리에서 영영 사라질것이고..
그니까 처음 토큰 까뒤집을때 컨텍스트 홀더라는 이름의 객체에 유저 정보를 세팅해두고 이후의 사이클에서 사용할 수 있도록 만들어둔게 아닌가 싶음
인증정보가 하나의 요청을 처리할 동안만 유효하다는 표현보다는 매 요청 처리가 끝나면 그 요청은 사라져버리니 당연히 다시 토큰 까뒤집어서 세팅해야한다..가 맞는 말일거같애
스프링은 하나의 쓰레드가 http 요청을 처리하고 이 쓰레드가 컨텍스트 홀더를 가짐 응답을 보내고 컨텍스트의 생명주기가 끝남 즉 요청을 처리하는 동안 해당 쓰레드가 jwt의 인증정보를 가지고 있는 컨텍스트 홀더를 사용하는거지 - dc App
Spring web mvc에서는 시큐리티 컨텍스트가 threadlocal로 저장되서 스레드마다 하나씩 설정됨 근데 요청이 오면 그때마다 스레드 하나 스레드풀에서 꺼내다가 쓰는데 여기에 있는 threadlocal은 걍 비어있는 놈임 그래서 매 요청마다 스레드 할당되면 여기에 시큐리티 컨텍스트 집어 넣어야되는거
매 요청마다 해도 크게 상관없음 Jwt 사용하는 이유 중 하나가 디비 접근 매번 안하려고임